Ему задашь вопрос и он тут же выдает информацию, как оно работает и почему. Ему расскажешь, что в принципе нужно, он тут же очень хорошо спроектирует все изменения наиболее быстрым и оптимальным способом.
Создается ощущение, что у человека «супермозг». Пользователи так часто и говорят.
Все из-за сложности системы.
Может ли система жить без системного архитектора? Может. Но недолго. Один, два, три года. Дальше существенная деградация.
Является ли это отторгаемой функцией? Можно ли ее купить на стороне? Вряд ли. Из-за сложностей в погружении.
О статье:
В чем схожесть проектной документации и англо-китайского словаря?
Чем отличается понимание системы и владение иностранным языком?
Почему наличие качественной документации не панацея?
Примеры провальных проектов ERP-систем. В чем причина?
Когда на протяжении длительного времени наблюдаешь за жизненным циклом ERP-систем, начинаешь замечать схожести даже там, где они не очевидны. Пару примеров таких ситуаций про внедрение erp систем:
- Проектная команда выполняет проект внедрения ERP на промышленном предприятии, проект не маленький (9 месяцев), дальше еще фаза стабилизации – полгода. Проект заканчивается успешно (хоть и со сдвигом сроков). Начинается поддержка erp системы.
Ключевые специалисты, которые выполняют проект, уходят выполнять другие проекты. Служба поддержки берется за свою часть работы.
Но развитие конфигурации дается с трудом. Заказчик не доволен результатом работы группы поддержки – она имеет полный комплект документов на систему, но те задачи, которые раньше решались за полчаса, теперь занимают по несколько дней.
В системе нарастает количество изменений, которые внесли уже на этапе поддержки и развития разные специалисты, отчего система начинает понемногу деградировать. В конце концов падает производительность, начинает хромать документация, разработчики уже боятся что-то дальше менять, все чаще говорят о том, что нужно пере-внедрение системы.
Неинтересный финал через 3 года после запуска системы.
- Вторая ситуация – у Заказчика в штате несколько лет работал системный архитектор. Создал систему (при этом участие принимало много ребят), но архитектура была сконцентрирована у одного человека. Система развивалась быстро. Изменения вносились оперативно. Качество документирования было на отличном уровне.
Но в какой-то момент системный архитектор увольняется. Документация есть. «Руки» тоже. А процесс деградации все равно начинается. Через 2-3 года система в запущенном состоянии. Приходят многие грамотные ребята. С документацией действительно отлично. Но почему-то «не заводится». Финал тот же.
Но вдруг возвращается системный архитектор обратно, берет все в свои руки, и не проходит полгода, как скорость работы растет, изменения делаются очень быстро. Заказчик доволен.
Таких примеров, если посмотреть на временные интервалы в 5-7 лет, очень много.
Что это? Гений первого архитектора? Просто не смогли подобрать второго архитектора?
Не может быть – слишком много таких примеров, и слишком много хороших спецов за это брались.
ИТ-директора пытаются защититься от этого качественным документированием разработок. Это что-то дает, но итоговый результат статистически такой же. Документирование разработки не решает вопрос. Просто оттягивает время.
Похоже на то, что есть еще что-то.
Роль системного архитектора в проекте
ERP-система очень сложна. Тысячи связей, моделей, таблиц, функций, процедур. Когда системный архитектор создает, модифицирует, дорабатывает, все это откладывается на кончиках пальцев. Да, документация делается, но редко какой хороший архитектор ее использует. Он и так «знает».
Ему задашь вопрос и он тут же выдает информацию, как оно работает и почему. Ему расскажешь, что в принципе нужно, он тут же очень хорошо спроектирует все изменения наиболее быстрым и оптимальным способом.
Часто он «чувствует» качество данных, поскольку пришлось с ними год очень плотно поработать. Ему очевидно, какой механизм даст качественный результат, а какой невозможно будет использовать в последствии.
Создается ощущение, что у человека «супермозг». Пользователи так часто и говорят.
Все из-за сложности системы.
Это как учить язык (объем словарного запаса очень похож). В словаре все есть, но кто-то говорит на нем спокойно (чувствует систему), а кто-то «читает со словарем» (документация).
Какой вывод из этого всего:
1. Системного архитектора хорошо бы не менять.
2. Если уж меняем, то нужно ОЧЕНЬ серьёзно подойти к освоению системы (успешных примеров смены такого архитектора немного).
Это не только время, это еще и методика изучения языка. Человек должен целенаправленно изучать (запоминать, а потом вырабатывать навыки) систему.
Сколько на это нужно будет времени? Сколько времени нужно на изучение нового языка?
Как не подвергнуть риску сложный проект? Рекомендации по внедрению проекта
При выполнении проектов, которыми мы занимаемся, есть два варианта:
1. Система закрывает локальную функцию. Например, автоматизирует адресное хранение. Не предполагается ее дальнейшее активное изменение, доработка (по мере жизни предприятия).
a. Здесь данный вопрос уходит на второй план: работает – не трогай.
2. Но если ERP-система предприятия, которая в идеале предприятию должна дать конкурентное преимущество, изменяется по мере трансформации бизнес-процессов самого предприятия, то здесь системный архитектор должен быть свой, внутренний. Не от подрядчика (который уйдет сразу после окончания проекта). Должен пропускать через себя все изменения в системе, которые делают любые участники процесса. Он должен их (изменения) формулировать, согласовывать, и контролировать результат.
Может ли система жить без системного архитектора? Может. Но недолго. Один, два, три года. Дальше существенная деградация.
Является ли это отторгаемой функцией? Можно ли ее купить на стороне? Вряд ли. Из-за сложностей в погружении.
По сути это означает, что те классические подходы, которые мы применяем к выполнению проектов, когда берем на себя как подрядчик все области, включая обеспечение архитектуры, не эффективные. Если проект «в долгую», то архитектор у Заказчика должен быть свой. Он должен быть активным участником процесса внедрения ERP-системы.
Это уже похоже не на ведение проекта нашей командой, а использование нашей команды в части «рабочей силы» для архитектора Заказчика. Как ни печально, но похоже такие модели «в долгую» более успешны для Заказчиков.
Какой процент Заказчиков это понимает?
Related Posts
Оценка и планирование проекта
Мысли о видах информационных систем…
Конфигурация "Выдача пропусков и учет рабочего времени"
Управление ИТ-проектами. Модуль 3: продвинутый курс по гибкому управлению проектами. Agile. Первый поток. Вебинары проходят с 11 сентября по 27 ноября 2024 г.
Загрузка/Выгрузка Excel для справочника "Графики работы сотрудников"
Онлайн-курсы по управлению ИТ-проектами от Марии Темчиной
1. Согласен что для сложной системы с продолжительным периодом внедрения требуется и последующей доработкой требуется «некоторое» постоянство
2. Разве у компании внедренца нет желания и дальнейшего сопровождения, продукта?
Правильная организация сопровождения и внесения изменений , а не «супермозг».
Информатика, точная наука 🙁
(2)
Информатика, точная наука 🙁
«Правильная организация» может оказаться настолько дорогим процессом, что «организм» ее просто не выдержит.
А вообще, понравилось. Сложность погружения — стоимость владения — супер мозг.
Читаешь — «словно подтираешь задницу шелком» © Матрица
Извиняюсь за вульгарщину. Никого не хотел обидеть — просто навеяло.
Проблема всегда в кадрах. Как эксперта по технологическим вопросам ни назови — хоть архитектором, хоть гуру, хоть заместителем директора департамента ИТ (или даже руководителем АСУ) — это ничего не меняет. Есть эксперт — есть развитие системы и понимание того, что нужно делать, если система стала вести себя не очень хорошо. Нет эксперта — хоть что делай, а при непонимании того, что нужно делать, далеко не уедешь. Как верно заметил Лустин (хоть я и не всегда с ним соглашаюсь): «!».
В условиях перманентного кризиса бизнес столько может не прожить. Меняются условия ведения бизнеса, значит требуется приводить в соответствие информационные (в т.ч. и ERP) системы: тут не только архитектор, а вся команда нужна. С инвестициями плохо, и будет хуже, поэтому сейчас выживают простые бизнесы. Вот и теряется со стороны руководства интерес к подобным системам
Андрей, все расписал верно.
1. Проектная команда под ключ от франча нужна, когда у заказчика нет ничего. В идеале архитектор должен быть у заказчика, но на нулевой точке это пока редкость.
2. Чем моложе собственники бизнеса, тем лучше они понимают необходимость в собственном архитекторе.
Я думаю пока небольшой. Но он будет расти.
(6) Зачастую собственники рубят бабло и не задумываются, о том как оно у них так получается. Учетные системы для них уже как самом собой разумеющееся и часто бытует мнение, что программисты тунеядцы, чем это они там занимаются??? Перестают ценить, начинают нагибать по теме аля тыж программист, дуй организуй установку сплит систем. Программисты тоже люди, берут уходят, а потом выясняется, что один программист обрабатывал половину подразделений организации, то там что-то за кого-то делал, то там, а все из-за низкоквалифицированных кадров, способных в однокакашниках переписываться и не о чем не думать. Так же и с архитекторами, все на себе волочешь, знаешь все бизнес процессы организации, даже порой лучше чем те люди, кто их должен знать в отделах. Не мудрено, что потеря таких людей вызывает системный сбой.
Автор, Вы говорите, что архитектор может уволиться. На вопрос, как всё должно работать в этом случае, ответа нет.
Это еще и провал системы обучения.
Есть такое понятие как «утраченная технология». Если человек изобрел технологию, и никого не может ей научить, то технология становится утраченной.
Я немного утрирую например, для отопления помещения надо повернуть краник в углу, и в результате в батареи пойдет горячая вода и будет тепло. Но человек ушел и или не сказал или было некому говорить. Новые люди чувствуют холод и вместо поворота крана покупают новый котел для обогрева.
Зависимость от конкретного специалиста — зло для компании, которую всячески избегаем, купируем внедрением процесса управления изменениями с метриками для оценки внесенных изменений- тем гарантируем себя от деградации системы.
Очень здорово описано.
С WMS похожая ситуация — когда заказчик решается самостоятельно поддерживать систему, то сколько бы документации не было, а результат один — за два три года система начинает деградировать, хотя до этого 5 лет развивалась и оставалась актуальной. Плюс еще накладывается, что программисты постоянно меняются и каждый приходит и привносит свой вклад.
Проблему — как сохранить, передать «Знание» …человечество пытается решить уже давно…))
Проблема, на самом деле, описывается банальным «не по сеньке шапка». Если у заказчика нет понимания, что кроме внедрения понадобится поддержка, по стоимости вполне себе сопоставимая, то результат заранее предсказуем. В простейшем случае хороший заказчик тупо выкупит себе архитектора 😉 Остальным не в коня корм будет полюбасу.
(12)
Успешно решает, но есть одно но: «научить можно всему, но не всех» (с)
(13) Если у внедренца нет понимания, что внедрение для Заказчика не самоцель, то это не внедренц, а банальный барыга с умным видом пытающийся впарить ненужную вещь…
Медаль всегда имеет две стороны…
(11) Программисты могут меняться и у подрядчика, что то же будет приводить к деградации, медленнее но будет, и это другие деньги нежели содержать своих.