Бессознательное и внедрение 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)

Недавно появилась новость "SAP дал сбой. "Сегежа Групп" отсудила 430 млн за цифровую трансформацию - Рамблер/личные финансы”. Очень примечательная, поскольку позволяет на реальном примере увидеть изнанку консалтинга в больших бюджетах: только факты, без слухов, без NDA и неофициальной информации. Мне эта тема особенно близка, поскольку я имею опыт работы в двух мирах — 1С и SAP , “ел устриц” и на kick – off и на разных стадиях проекта. Поэтому пристегивайтесь, вас ждет увлекательный разбор судебного решения А40-299276-2022__20250120. Цель статьи не потоптаться на костях SAP в России, а показать сообществу 1С, что влияет на успех проекта на больших масштабах. И заодно ответить на вопрос — светит ли успех 1С в узком, но богатом сегменте больших корпораций.

30.06.2025    1483    0    1CUnlimited    46    

32

Внедрение изменений Бизнес-аналитик Руководитель проекта 1С v8.3 1С:ERP Управление предприятием 2 Россия Бесплатно (free)

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

20.06.2025    771    0    Adapta    15    

6

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

1С:ERP имеет сложную внутреннюю структуру, но очень слабую «защиту от дурака». Пользователи легко могут совершать ошибки, приводящие к «расползанию» регистров и проводок. Пока проект сопровождают внедренцы, контроль за корректностью ведётся, но как только система передаётся в руки локальной ИТ-службы, начинают появляться проблемы. Новые пользователи могут невнимательно изучать инструкции, некорректно заполнять документы, да и сама программа меняется от версии к версии, что усложняет ситуацию вплоть до того, что количество ошибок и расхождений данных возрастает до уровня «ваша программа вообще не работает». Расскажем о том, как проходит процесс внедрения 1С:ERP, и что происходит после завершения проекта.

19.06.2025    14285    35    VeraPikuren    6    

12

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

Разберемся, чем отличаются конструкторская, технологическая и производственная спецификации – и почему их путаница приводит к ошибкам. Узнаем, какие бывают виды материалов в спецификациях и почему фраза «НСИ у нас в актуальном состоянии» не гарантирует готовности к работе. А также поразмышляем о том, на какие подводные камни стоит обратить внимание, чтобы избежать срывов сроков и переделок.

19.06.2025    697    0    VeraPikuren    1    

6

Оптимизация бизнес-процессов Проектирование бизнес-процессов Внедрение изменений 1С v8.3 1С:ERP. Управление холдингом Бесплатно (free)

Как создать систему планирования на реальном производстве с нуля, не используя готовые ERP-решения? В этой статье программист делится опытом внедрения собственной системы планирования в условиях крупного производства очистных сооружений. Рассказано о том, как начать с понимания процессов, спроектировать документ «Планирование производства», реализовать механизм распределения задач между бригадами и интегрировать всё с учётом материалов и выпуском продукции. Статья покажет, что даже в сложных условиях можно сделать простое и рабочее решение — без излишней автоматизации, но с фокусом на реальные потребности пользователей.

10.06.2025    708    0    KHoroshulinAV    6    

8

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

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

28.04.2025    1058    0    chavalah    0    

6

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

Внедрение дорогих и сложных решений вроде BI, MDM, CRM или УХ для вспомогательных целей – не единственный путь, а порой и вовсе тупиковый. Расскажем о том, как не попасть в УХу, если директор хочет красивые отчёты, и делать дешёвые интеграции, не заморачиваясь с поиском специалистов по Конвертации данных.

01.04.2025    6422    0    1c-intelligence    24    

43

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

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

11.03.2025    573    0    Radio_Analyst    0    

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


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

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

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

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

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

Я думаю пока небольшой. Но он будет расти.
golovinaea; Brawler; +2 Ответить
7. Brawler 461 01.05.17 23:23 Сейчас в теме
(6) Зачастую собственники рубят бабло и не задумываются, о том как оно у них так получается. Учетные системы для них уже как самом собой разумеющееся и часто бытует мнение, что программисты тунеядцы, чем это они там занимаются??? Перестают ценить, начинают нагибать по теме аля тыж программист, дуй организуй установку сплит систем. Программисты тоже люди, берут уходят, а потом выясняется, что один программист обрабатывал половину подразделений организации, то там что-то за кого-то делал, то там, а все из-за низкоквалифицированных кадров, способных в однокакашниках переписываться и не о чем не думать. Так же и с архитекторами, все на себе волочешь, знаешь все бизнес процессы организации, даже порой лучше чем те люди, кто их должен знать в отделах. Не мудрено, что потеря таких людей вызывает системный сбой.
vakham; golovinaea; sergathome; +3 Ответить
8. Aphanas 93 02.05.17 05:04 Сейчас в теме
Автор, Вы говорите, что архитектор может уволиться. На вопрос, как всё должно работать в этом случае, ответа нет.
vakham; Evgen2866; ipoloskov; +3 Ответить
9. Green2 29 02.05.17 08:10 Сейчас в теме
Это еще и провал системы обучения.
Есть такое понятие как "утраченная технология". Если человек изобрел технологию, и никого не может ей научить, то технология становится утраченной.
Я немного утрирую например, для отопления помещения надо повернуть краник в углу, и в результате в батареи пойдет горячая вода и будет тепло. Но человек ушел и или не сказал или было некому говорить. Новые люди чувствуют холод и вместо поворота крана покупают новый котел для обогрева.
vakham; golovinaea; SlavaKron; sergathome; +4 Ответить
10. ВикторП 352 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 3180 10.05.17 22:48 Сейчас в теме
(12)
пытается решить уже давно...
Успешно решает, но есть одно но: "научить можно всему, но не всех" (с)
13. sergathome 4 10.05.17 15:07 Сейчас в теме
Проблема, на самом деле, описывается банальным "не по сеньке шапка". Если у заказчика нет понимания, что кроме внедрения понадобится поддержка, по стоимости вполне себе сопоставимая, то результат заранее предсказуем. В простейшем случае хороший заказчик тупо выкупит себе архитектора ;) Остальным не в коня корм будет полюбасу.
15. dddxddd 24.06.17 14:47 Сейчас в теме
(13) Если у внедренца нет понимания, что внедрение для Заказчика не самоцель, то это не внедренц, а банальный барыга с умным видом пытающийся впарить ненужную вещь...
Медаль всегда имеет две стороны...
Оставьте свое сообщение