KoderLine
Обслуживание
и внедрение
+7 (495) 374 55 29 Обратный звонок

Статьи экспертов

Полезная информация

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

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

3
1258
07.02.2017 Андрей Бербека
   

Об авторе:

… 15 лет опыта выполнения проектных работ

 
     
    Бербека 002.jpg  
     
 

Содержание:

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

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

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

 
     
 

О статье:

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

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

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

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

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

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

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

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

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

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

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

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

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

 
     
 

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

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

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

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

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

 
     
 

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

 
     
 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 
     
 

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

 
     
   

Андрей Бербека,

генеральный директор ООО “Кодерлайн”

 
     


0
Guest
Есть Инженер - есть решение, а системный архитектор - это от лукавого.
Имя Цитировать 0
0
Олег
Не надо пытаться создавать универсальную конфигурацию перевожу создать -(экскаваторосамолето-подводнаялодкакосмитескаястанциявелосипедоэлектромобилескутр­е и т.д.)создать не возможно точка.И будет Вам счастье по сути ерп 2. использование среднестатистическим предприятием изначально провальный проект!!!Там где среднестатистическому пользователю надо для того что бы завести справочник номенклатура запрограммировать самому(ха-ха а он ни разу не программист)) заполнение справочника виды номенклатуры, написать самому отчет в системе компановки данных - последствия печальны. А учитывая динамику изменяющихся условий бизнеса (не в СССР живем), люди по 30 лет на одном месте и одном предприятии не работают). Т.Е позволить использования этого нетленного шедевра ЕРП - могут позволить себе только очень крупные и богатые предприятия с неиссякаемым ресурсом на IT.
Имя Цитировать 0
0
Евгений Ханыков
Полностью солидарен с автором. На все 100%. Только к системному архитектору еще нужен Заказчик решения, который понимает, что хочет. Может это Финансовый директор, может Генеральный, может собственник. И вот тогда взлетит. И, действительно, потеря этого архитектора будет катастрофой для предприятия. Не знаю как там на западе... скорей всего, все же, так же как и у нас, но мы берем систему и всегда начинаем ее подправлять под себя. И это правильно...!!! Нельзя завод переделывать под программу - это ненормально. И для того, чтобы правильно подправлять нужен СВОЙ, ВНУТРЕННИЙ работник, на позиции ТОПа, который будет развивать и поддерживать систему (если это действительно ERP). Если же мы строим ячеистое хранение или CRM для коммерческого, то ничего такого не надо. ЭТО НУЖНО ТОЛЬКО ДЛЯ ERP. Там, где нужна взаимосвязь между разными большими задачами.



Мне кажется, что коллеги, кто комментировал статью не совсем правильно поняли то, что пытался донести Автор. Андрей говорил про Комплексную систему, а не про конфигурацию 1С, которую надо подпилить напильником...
Имя Цитировать 0
Добавить комментарий
Текст сообщения*
Защита от автоматических сообщений
 
Теги
#1С: CRM #1С: ERP #1С: ERP Управление строительной организацией #1С: ERP. Управление буровой компанией #1С: WMS Управление складом #1С: Аренда и управление недвижимостью #1С: БУХ #1С: Договорчики #1С: Документооборот #1С: ЗУП #1С: Интеграция #1С: КА #1С: Колледж #1С: Конвертация данных #1С: Платформа #1С: Розница #1С: Сценарное тестирование #1С: ТОИР #1С: УАТ #1С: УКФ #1С: Университет #1С: УНФ #1С: УПП #1С: Управление строительной организацией #1С: УТ #1С: УХ #ADO #APACHE #API #com-объекты #Excel #GoogleDrive #HTTP #Koderline: Управление медиа-холдингом #Koderline: Управление проектами строительства скважин #LINUX #MS SQL Server #WEB #WEB-сервисы 1С #Word #XML #Администрирование 1С #Безопасность сервера #Бесшовная интеграция #БИТ.Финанc #Битрикс24 #Блокировки в 1С #БСП #БУ #Бурение скважин #Бюджетирование #Внедрение #Внедрение ERP #Закрытие месяца #Запросы 1С #Интеграция 1С #Как сделать в 1С #Конвертация данных #Корпоративное сопровождение #Лизинг #Лицензии 1С #Моделирование #МСФО #Налоги #Обмен между базами #Обновления #Оптимизация #Отпуск #Отчетность #Отчеты в 1С #Оценка задач #Перенос данных #Планирование #Полезные обработки #Правила обмена #Проводки 1С #Программирование в 1С #Программные права #Продажи #Производство #Расширение конфигурации #РСБУ #СКД #Сравнение конфигураций #Тестирование 1С #Техническое задание #Торговое оборудование #Транспортная логистика #Управление проектами #Финансовый учет #Ценообразование #Экзамен 1С #Яндекс.Касса
Услуги программиста 1С
Получите специалиста  
для решения всех задач
в области 1С
Программы 1С
Цены и подробное описание программ 1С:Предприятие 8.
Яндекс.Метрика