Бессознательное и внедрение ERP-систем. Роль системного архитектора в проекте

28.04.17

Бизнес-анализ

ERP-система очень сложна. Тысячи связей, моделей, таблиц, функций, процедур. Когда системный архитектор создает, модифицирует, дорабатывает, все это откладывается на кончиках пальцев. Да, документация делается, но редко какой хороший архитектор ее использует. Он и так "знает". Ему задашь вопрос и он тут же выдает информацию, как оно работает и почему. Ему расскажешь, что в принципе нужно, он тут же очень хорошо спроектирует все изменения наиболее быстрым и оптимальным способом. Создается ощущение, что у человека "супермозг". Пользователи так часто и говорят. Все из-за сложности системы. Может ли система жить без системного архитектора? Может. Но недолго. Один, два, три года. Дальше существенная деградация. Является ли это отторгаемой функцией? Можно ли ее купить на стороне? Вряд ли. Из-за сложностей в погружении.

О статье:

В чем схожесть проектной документации и англо-китайского словаря?

Чем отличается понимание системы и владение иностранным языком?

Почему наличие качественной документации не панацея?

Примеры провальных проектов ERP-систем. В чем причина?

Когда на протяжении длительного времени наблюдаешь за жизненным циклом ERP-систем, начинаешь замечать схожести даже там, где они не очевидны. Пару примеров таких ситуаций про внедрение erp систем:

  •  Проектная команда выполняет проект внедрения ERP на промышленном предприятии, проект не маленький (9 месяцев), дальше еще фаза стабилизации – полгода. Проект заканчивается успешно (хоть и со сдвигом сроков). Начинается поддержка erp системы.

Ключевые специалисты, которые выполняют проект, уходят выполнять другие проекты. Служба поддержки берется за свою часть работы.

Но развитие конфигурации дается с трудом. Заказчик не доволен результатом работы группы поддержки – она имеет полный комплект документов на систему, но те задачи, которые раньше решались за полчаса, теперь занимают по несколько дней.

В системе нарастает количество изменений, которые внесли уже на этапе поддержки и развития разные специалисты, отчего система начинает понемногу деградировать. В конце концов падает производительность, начинает хромать документация, разработчики уже боятся что-то дальше менять, все чаще говорят о том, что нужно пере-внедрение системы.

Неинтересный финал через 3 года после запуска системы.

  • Вторая ситуация – у Заказчика в штате несколько лет работал системный архитектор. Создал систему (при этом участие принимало много ребят), но архитектура была сконцентрирована у одного человека. Система развивалась быстро. Изменения вносились оперативно. Качество документирования было на отличном уровне. 

Но в какой-то момент системный архитектор увольняется. Документация есть. "Руки" тоже. А процесс деградации все равно начинается. Через 2-3 года система в запущенном состоянии. Приходят многие грамотные ребята. С документацией действительно отлично. Но почему-то "не заводится". Финал тот же.

Но вдруг возвращается системный архитектор обратно, берет все в свои руки, и не проходит полгода, как скорость работы растет, изменения делаются очень быстро. Заказчик доволен.

Таких примеров, если посмотреть на временные интервалы в 5-7 лет, очень много.

Что это? Гений первого архитектора? Просто не смогли подобрать второго архитектора?

Не может быть – слишком много таких примеров, и слишком много хороших спецов за это брались.

ИТ-директора пытаются защититься от этого качественным документированием разработок. Это что-то дает, но итоговый результат статистически такой же. Документирование разработки не решает вопрос. Просто оттягивает время.

Похоже на то, что есть еще что-то.

Роль системного архитектора в проекте

ERP-система очень сложна. Тысячи связей, моделей, таблиц, функций, процедур. Когда системный архитектор создает, модифицирует, дорабатывает, все это откладывается на кончиках пальцев. Да, документация делается, но редко какой хороший архитектор ее использует. Он и так "знает".

Ему задашь вопрос и он тут же выдает информацию, как оно работает и почему. Ему расскажешь, что в принципе нужно, он тут же очень хорошо спроектирует все изменения наиболее быстрым и оптимальным способом.

Часто он "чувствует" качество данных, поскольку пришлось с ними год очень плотно поработать. Ему очевидно, какой механизм даст качественный результат, а какой невозможно будет использовать в последствии.

Создается ощущение, что у человека "супермозг". Пользователи так часто и говорят.

Все из-за сложности системы.

Это как учить язык (объем словарного запаса очень похож). В словаре все есть, но кто-то говорит на нем спокойно (чувствует систему), а кто-то "читает со словарем" (документация).

Какой вывод из этого всего:

1.       Системного архитектора хорошо бы не менять.

2.       Если уж меняем, то нужно ОЧЕНЬ серьёзно подойти к освоению системы (успешных примеров смены такого архитектора немного).

Это не только время, это еще и методика изучения языка. Человек должен целенаправленно изучать (запоминать, а потом вырабатывать навыки) систему.

Сколько на это нужно будет времени? Сколько времени нужно на изучение нового языка?

 Как не подвергнуть риску сложный проект? Рекомендации по внедрению проекта

При выполнении проектов, которыми мы занимаемся, есть два варианта:

1.       Система закрывает локальную функцию. Например, автоматизирует адресное хранение. Не предполагается ее дальнейшее активное изменение, доработка (по мере жизни предприятия).

a.       Здесь данный вопрос уходит на второй план: работает – не трогай.

2.       Но если ERP-система предприятия, которая в идеале предприятию должна дать конкурентное преимущество, изменяется по мере трансформации бизнес-процессов самого предприятия, то здесь системный архитектор должен быть свой, внутренний. Не от подрядчика (который уйдет сразу после окончания проекта). Должен пропускать через себя все изменения в системе, которые делают любые участники процесса. Он должен их (изменения) формулировать, согласовывать, и контролировать результат.

Может ли система жить без системного архитектора? Может. Но недолго. Один, два, три года. Дальше существенная деградация.

Является ли это отторгаемой функцией? Можно ли ее купить на стороне? Вряд ли. Из-за сложностей в погружении.

По сути это означает, что те классические подходы, которые мы применяем к выполнению проектов, когда берем на себя как подрядчик все области, включая обеспечение архитектуры, не эффективные. Если проект "в долгую", то архитектор у Заказчика должен быть свой. Он должен быть активным участником процесса внедрения ERP-системы.

Это уже похоже не на ведение проекта нашей командой, а использование нашей команды в части "рабочей силы" для архитектора Заказчика. Как ни печально, но похоже такие модели "в долгую" более успешны для Заказчиков.

Какой процент Заказчиков это понимает?

#1С: ERP #Управление проектами #Системный архитектор #Внедрение #Внедрение ERP

См. также

Фаза пресейла: насколько глубоко нужно погружаться в бизнес-домен?

Анализ предметной области Анализ потребностей и поиск решений Бесплатно (free)

В статье объясним значение погружения в бизнес-домен, расскажем о возможных проблемах и ограничениях, а также путях поиска информации о бизнес-домене.

25.03.2024    346    0    alenkaiva    0    

3

Как реорганизовать работу проектного департамента, чтобы быть №1

Внедрение изменений Бесплатно (free)

Методики быстрореагирующего производства и QRM-ячейки применимы не только к станкам, но и к проектным командам. О том, как за счет разделения проектного офиса на многофункциональные QRM-ячейки обеспечить равномерную загрузку работу сотрудников, вырасти в два раза и существенно повысить лояльность заказчиков и коллектива, пойдет речь в статье.

14.02.2024    618    0    user1270271    2    

7

Управление ожиданиями на проекте

Работа с заинтересованными сторонами Бесплатно (free)

Каждый человек, который включается в проект после согласования контура автоматизации, имеет свое внутреннее понимание того, как должна работать система. О том, как определить в проекте ключевых функциональных специалистов и конкретные цели, поддерживать открытость при взаимодействии с заказчиком и передать проект на сервисное сопровождение, расскажем в статье.

08.02.2024    536    0    izybaevda    0    

5

Как внедрить 1С:ERP за 2 года и не сойти с ума

Анализ предметной области Анализ потребностей и поиск решений Внедрение изменений Бесплатно (free)

Для руководителей подразделений новые проекты вызывают желание получить максимальный эффект от реализации идей, а также опасения, верно ли выбран ориентир нововведений. О том, как справиться с трудностями, дойти до цели и внедрить 1С:ERP на производственном предприятии, ежедневно выпускающем десятки тысяч единиц готовой продукции, расскажем в статье.

30.01.2024    7085    0    user1578851    16    

16

Свободное программное обеспечение в крупной компании – миф или реальность? Как мы переводили 2500 пользователей на Linux

Внедрение изменений Бесплатно (free)

Переход на свободное программное обеспечение – серьезное испытание и для бизнес-пользователей, и для ИТ-подразделения. Нужно учесть много факторов, найти компромиссы и поменять привычки. О «пяти стадиях принятия неизбежного» и успешном преодолении трудностей при переводе ИТ-инфраструктуры автодилерских центров на Linux расскажем в статье.

29.01.2024    2489    0    user1063453    2    

5

Зачем нужны аналитики на проектах автоматизации

Анализ потребностей и поиск решений Бесплатно (free)

Исторически сложилось так, что аналитик 1С многими воспринимается как вечный падаван, который обеспечивает разработчиков информацией, а пользователей – инструкциями. Не согласимся с таким подходом и на примере реального кейса покажем, почему именно аналитик должен стать лидером проекта автоматизации.

18.01.2024    1669    0    user1754524    19    

12

Радио "Аналитик", 7 выпуск 2 сезона. Про работу аналитика с бизнесом и повышение бизнес-компетенций с Константином Семёновым

Анализ предметной области Работа с заинтересованными сторонами Анализ потребностей и поиск решений

В седьмом выпуске второго сезона подкаста Радио “Аналитик“ поговорили о том, что такое бизнес-компетенции, для чего они нужны аналитику, к чему может привести их отсутствие и как их развивать.

28.11.2023    476    0    Radio_Analyst    0    

2
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. ivanov660 4344 28.04.17 15:45 Сейчас в теме
1. Согласен что для сложной системы с продолжительным периодом внедрения требуется и последующей доработкой требуется "некоторое" постоянство
2. Разве у компании внедренца нет желания и дальнейшего сопровождения, продукта?
+
2. ВикторП 343 28.04.17 17:32 Сейчас в теме
Правильная организация сопровождения и внесения изменений , а не "супермозг".
Информатика, точная наука :(
+
3. script 128 28.04.17 18:15 Сейчас в теме
(2)
Правильная организация сопровождения и внесения изменений , а не "супермозг".
Информатика, точная наука :(


"Правильная организация" может оказаться настолько дорогим процессом, что "организм" ее просто не выдержит.

А вообще, понравилось. Сложность погружения - стоимость владения - супер мозг.
Читаешь - "словно подтираешь задницу шелком" © Матрица
Извиняюсь за вульгарщину. Никого не хотел обидеть - просто навеяло.
Gorus; +1
4. starik-2005 3036 29.04.17 13:13 Сейчас в теме
Проблема всегда в кадрах. Как эксперта по технологическим вопросам ни назови - хоть архитектором, хоть гуру, хоть заместителем директора департамента ИТ (или даже руководителем АСУ) - это ничего не меняет. Есть эксперт - есть развитие системы и понимание того, что нужно делать, если система стала вести себя не очень хорошо. Нет эксперта - хоть что делай, а при непонимании того, что нужно делать, далеко не уедешь. Как верно заметил Лустин (хоть я и не всегда с ним соглашаюсь): "Всем нужен эксперт!".
khomichevskaya; +1
5. Now 17 01.05.17 13:33 Сейчас в теме
Может ли система жить без системного архитектора? Может. Но недолго. Один, два, три года.

В условиях перманентного кризиса бизнес столько может не прожить. Меняются условия ведения бизнеса, значит требуется приводить в соответствие информационные (в т.ч. и ERP) системы: тут не только архитектор, а вся команда нужна. С инвестициями плохо, и будет хуже, поэтому сейчас выживают простые бизнесы. Вот и теряется со стороны руководства интерес к подобным системам
shard; +1
6. Gureev 01.05.17 15:49 Сейчас в теме
Андрей, все расписал верно.

1. Проектная команда под ключ от франча нужна, когда у заказчика нет ничего. В идеале архитектор должен быть у заказчика, но на нулевой точке это пока редкость.
2. Чем моложе собственники бизнеса, тем лучше они понимают необходимость в собственном архитекторе.

Какой процент Заказчиков это понимает?

Я думаю пока небольшой. Но он будет расти.
golovinaea; Brawler; +2
7. Brawler 455 01.05.17 23:23 Сейчас в теме
(6) Зачастую собственники рубят бабло и не задумываются, о том как оно у них так получается. Учетные системы для них уже как самом собой разумеющееся и часто бытует мнение, что программисты тунеядцы, чем это они там занимаются??? Перестают ценить, начинают нагибать по теме аля тыж программист, дуй организуй установку сплит систем. Программисты тоже люди, берут уходят, а потом выясняется, что один программист обрабатывал половину подразделений организации, то там что-то за кого-то делал, то там, а все из-за низкоквалифицированных кадров, способных в однокакашниках переписываться и не о чем не думать. Так же и с архитекторами, все на себе волочешь, знаешь все бизнес процессы организации, даже порой лучше чем те люди, кто их должен знать в отделах. Не мудрено, что потеря таких людей вызывает системный сбой.
vakham; golovinaea; sergathome; +3
8. Aphanas 92 02.05.17 05:04 Сейчас в теме
Автор, Вы говорите, что архитектор может уволиться. На вопрос, как всё должно работать в этом случае, ответа нет.
vakham; Evgen2866; ipoloskov; +3
9. Green2 29 02.05.17 08:10 Сейчас в теме
Это еще и провал системы обучения.
Есть такое понятие как "утраченная технология". Если человек изобрел технологию, и никого не может ей научить, то технология становится утраченной.
Я немного утрирую например, для отопления помещения надо повернуть краник в углу, и в результате в батареи пойдет горячая вода и будет тепло. Но человек ушел и или не сказал или было некому говорить. Новые люди чувствуют холод и вместо поворота крана покупают новый котел для обогрева.
vakham; golovinaea; SlavaKron; sergathome; +4
10. ВикторП 343 02.05.17 12:00 Сейчас в теме
Зависимость от конкретного специалиста - зло для компании, которую всячески избегаем, купируем внедрением процесса управления изменениями с метриками для оценки внесенных изменений- тем гарантируем себя от деградации системы.
+
11. rsergio 80 03.05.17 10:06 Сейчас в теме
Очень здорово описано.

С WMS похожая ситуация - когда заказчик решается самостоятельно поддерживать систему, то сколько бы документации не было, а результат один - за два три года система начинает деградировать, хотя до этого 5 лет развивалась и оставалась актуальной. Плюс еще накладывается, что программисты постоянно меняются и каждый приходит и привносит свой вклад.
+
16. kaging 8 29.11.18 15:04 Сейчас в теме
(11) Программисты могут меняться и у подрядчика, что то же будет приводить к деградации, медленнее но будет, и это другие деньги нежели содержать своих.
+
12. Vasas2007 07.05.17 08:57 Сейчас в теме
Проблему - как сохранить, передать "Знание" ...человечество пытается решить уже давно...))
+
14. starik-2005 3036 10.05.17 22:48 Сейчас в теме
(12)
пытается решить уже давно...
Успешно решает, но есть одно но: "научить можно всему, но не всех" (с)
+
13. sergathome 4 10.05.17 15:07 Сейчас в теме
Проблема, на самом деле, описывается банальным "не по сеньке шапка". Если у заказчика нет понимания, что кроме внедрения понадобится поддержка, по стоимости вполне себе сопоставимая, то результат заранее предсказуем. В простейшем случае хороший заказчик тупо выкупит себе архитектора ;) Остальным не в коня корм будет полюбасу.
+
15. dddxddd 24.06.17 14:47 Сейчас в теме
(13) Если у внедренца нет понимания, что внедрение для Заказчика не самоцель, то это не внедренц, а банальный барыга с умным видом пытающийся впарить ненужную вещь...
Медаль всегда имеет две стороны...
+
Оставьте свое сообщение