|
Об авторе: … 15 лет опыта выполнения проектных работ |
||
|
||
|
Содержание: 1. Примеры провальных проектов ERP-систем. В чем причина? 2. Роль системного архитектора в проекте. 3. Как не подвергнуть риску сложный проект? Рекомендации по внедрению проекта. |
||
|
О статье: В чем схожесть проектной документации и англо-китайского словаря? Чем отличается понимание системы и владение иностранным языком? |
||
| Примеры провальных проектов ERP-систем. В чем причина? | ||
|
Когда на протяжении длительного времени наблюдаешь за жизненным циклом ERP-систем, начинаешь замечать схожести даже там, где они не очевидны. Пару примеров таких ситуаций про внедрение erp систем: · Проектная команда выполняет проект внедрения ERP на промышленном предприятии, проект не маленький (9 месяцев), дальше еще фаза стабилизации – полгода. Проект заканчивается успешно (хоть и со сдвигом сроков). Начинается поддержка erp системы. Ключевые специалисты, которые выполняют проект, уходят выполнять другие проекты. Служба поддержки берется за свою часть работы. Но развитие конфигурации дается с трудом. Заказчик не доволен результатом работы группы поддержки – она имеет полный комплект документов на систему, но те задачи, которые раньше решались за полчаса, теперь занимают по несколько дней. В системе нарастает количество изменений, которые внесли уже на этапе поддержки и развития разные специалисты, отчего система начинает понемногу деградировать. В конце концов падает производительность, начинает хромать документация, разработчики уже боятся что-то дальше менять, все чаще говорят о том, что нужно пере-внедрение системы.
Неинтересный финал через 3 года после запуска системы.
· Вторая ситуация – у Заказчика в штате несколько лет работал системный архитектор. Создал систему (при этом участие принимало много ребят), но архитектура была сконцентрирована у одного человека. Система развивалась быстро. Изменения вносились оперативно. Качество документирования было на отличном уровне.
Но в какой-то момент системный архитектор увольняется. Документация есть. "Руки" тоже. А процесс деградации все равно начинается. Через 2-3 года система в запущенном состоянии. Приходят многие грамотные ребята. С документацией действительно отлично. Но почему-то "не заводится". Финал тот же. Но вдруг возвращается системный архитектор обратно, берет все в свои руки, и не проходит полгода, как скорость работы растет, изменения делаются очень быстро. Заказчик доволен.
|
||
|
Таких примеров, если посмотреть на временные интервалы в 5-7 лет, очень много.
Что это? Гений первого архитектора? Просто не смогли подобрать второго архитектора? Не может быть – слишком много таких примеров, и слишком много хороших спецов за это брались.
ИТ-директора пытаются защититься от этого качественным документированием разработок. Это что-то дает, но итоговый результат статистически такой же. Документирование разработки не решает вопрос. Просто оттягивает время.
|
||
|
Роль системного архитектора в проекте
|
||
|
ERP-система очень сложна. Тысячи связей, моделей, таблиц, функций, процедур. Когда системный архитектор создает, модифицирует, дорабатывает, все это откладывается на кончиках пальцев. Да, документация делается, но редко какой хороший архитектор ее использует. Он и так "знает". Ему задашь вопрос и он тут же выдает информацию, как оно работает и почему. Ему расскажешь, что в принципе нужно, он тут же очень хорошо спроектирует все изменения наиболее быстрым и оптимальным способом. Часто он "чувствует" качество данных, поскольку пришлось с ними год очень плотно поработать. Ему очевидно, какой механизм даст качественный результат, а какой невозможно будет использовать в последствии. Создается ощущение, что у человека "супермозг". Пользователи так часто и говорят.
Все из-за сложности системы.
Это как учить язык (объем словарного запаса очень похож). В словаре все есть, но кто-то говорит на нем спокойно (чувствует систему), а кто-то "читает со словарем" (документация).
Какой вывод из этого всего: 1. Системного архитектора хорошо бы не менять.
2. Если уж меняем, то нужно ОЧЕНЬ серьёзно подойти к освоению системы (успешных примеров смены такого архитектора немного).
Это не только время, это еще и методика изучения языка. Человек должен целенаправленно изучать (запоминать, а потом вырабатывать навыки) систему. Сколько на это нужно будет времени? Сколько времени нужно на изучение нового языка?
|
||
| Как не подвергнуть риску сложный проект? Рекомендации по внедрению проекта | ||
|
При выполнении проектов, которыми мы занимаемся, есть два варианта: 1. Система закрывает локальную функцию. Например, автоматизирует адресное хранение. Не предполагается ее дальнейшее активное изменение, доработка (по мере жизни предприятия). a. Здесь данный вопрос уходит на второй план: работает – не трогай. 2. Но если ERP-система предприятия, которая в идеале предприятию должна дать конкурентное преимущество, изменяется по мере трансформации бизнес-процессов самого предприятия, то здесь системный архитектор должен быть свой, внутренний. Не от подрядчика (который уйдет сразу после окончания проекта). Должен пропускать через себя все изменения в системе, которые делают любые участники процесса. Он должен их (изменения) формулировать, согласовывать, и контролировать результат.
Может ли система жить без системного архитектора? Может. Но недолго. Один, два, три года. Дальше существенная деградация. Является ли это отторгаемой функцией? Можно ли ее купить на стороне? Вряд ли. Из-за сложностей в погружении.По сути это означает, что те классические подходы, которые мы применяем к выполнению проектов, когда берем на себя как подрядчик все области, включая обеспечение архитектуры, не эффективные. Если проект "в долгую", то архитектор у Заказчика должен быть свой. Он должен быть активным участником процесса внедрения ERP-системы. Это уже похоже не на ведение проекта нашей командой, а использование нашей команды в части "рабочей силы" для архитектора Заказчика. Как ни печально, но похоже такие модели "в долгую" более успешны для Заказчиков. |
||
|
Какой процент Заказчиков это понимают? |
||
|
Андрей Бербека, генеральный директор ООО “Кодерлайн” |
||
