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

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

3
4465
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-системы.

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

 
     
 

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

 
     
   

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

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

 
     

Задать вопрос автору статьи
Тема вопроса*
Ваше имя*
E-mail или телефон*
Ваш вопрос*
 

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



Мне кажется, что коллеги, кто комментировал статью не совсем правильно поняли то, что пытался донести Автор. Андрей говорил про Комплексную систему, а не про конфигурацию 1С, которую надо подпилить напильником...
Имя Цитировать 0
Добавить комментарий
Текст сообщения*
Защита от автоматических сообщений
 
Теги
# абота Риелторского Агентства # Управление торговлей 11 #Работа Риелторского Агентства # 1C # CRM-система # Cинтаксис-помощник # Cинхронные методы работы # PDF документами # PowerShell # XML-файл # Бизнес-процесс # Глубина анализа # Графические объекты # Динамический список # Документ заполнен # Документ Отбор (размещение) товаров # Документ Отгрузка товаров ИС МП # Документ Приобретение товаров и услуг # Документ УПД # Доступ на ТСД # ДтКт # ЕАЭС # Закладка Администрирование # Зарплата и кадры # Имя таблицы # ИТС # Кабель NYM(Севкабель) 3x5.5 # Книга учета доходов и расходов # Курс валюты # Лицо с правом подписи # Лицо, имеющее право подписи документов # Маркировка цифровыми кодами # Минимальные цены продажи в 1С # Настройка НСИ и разделов # Настройка ценообразования # НДФЛ # Нематериальные активы # Обмен электронными документами # Оплата через банк # Основное ответственное лицо организации # Перемещение ТС и оборудования # Проведение инструктажа # Продажи или Закупки # Прочие доходы # Пункт Подключить обработки # Пункт Сервис # ПФР и ФФОМС # Работа ТС # Расчет налога УСН # Расчетные счета # Система «Честный знак» # Система GS1 # Списание на расходы # Справка-расчет налога УСН # Страховые взносы # Таблица формы # Таблица формы «Сотрудники» # Товары # Установка цен на товары # Формат Цифровой Маркировки # Функция Дата # Функция ДеньГода # Функция ДеньНедели # Центральный Банк России # Цены номенклатуры 2.5 # Элементы #1.6-НДФЛ #1С Бухгалтерия #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С: УТ #1С: УХ #1С:ERP #1С:БГУ #1С:БП #1С:Риелтор #1С:Управление холдингом #1С.6-НДФЛ #ADO #APACHE #API #canonical #com-объекты #Cправочник БИК #Excel #Excel в 1С #GoogleDrive #Googleаккаунт #HTTP #ITIL #Koderline: Управление медиа-холдингом #Koderline: Управление проектами строительства скважин #LINUX #MS SQL Server #PDF #WEB #WEB-сервисы 1С #Word #WS-ссылки #XDTO-объект #XML #XML-обмен #Администрирование 1С #Адрес URL описания #акты в 1С #Банковские счета #Безопасность сервера #Бесшовная интеграция #БИТ.Финанc #Битрикс24 #Блокировки в 1С #БСП #БУ #Бурение скважин #Бухгалтерская отчётность в МСФО #Бюджетирование #Вид Характеристики #Внедрение #Внедрение ERP #Внешний вид формы #Выбор каталога #Выбранные файлы #Документ Отпуск #Документ1 #Журналы #Загрузка цен в 1С #Задача для 1С #Закладка Торговля #Закрытие месяца #Заменить #Запись регистра сведений #Запросы 1С #Интеграция 1С #Интервал dpi #История пользователя #Кадровые документы #КАК ОТРАЖАЮТСЯ ТОВАРЫ В ПУТИ 1С #Как сделать в 1С #Карточка Объекта недвижимости #Классификаторы и курсы валют #Клиент-серверная схема #Код ЦМТ #Конвертация данных #Контроль документов #Конфигурация 1С #Конфигурация 1С ЗУП 3.1 #Копирование настроек пользователей #Корпоративное сопровождение #Лизинг #Лицензии 1С #Лицензионный договор #Личные документы #Массив Номенклатур #Массовая регистрация отгулов #Меню Отчет #Механизм Анализа Данных в 1С #Моделирование #Модуль Диадок #МРОТ #МСФО #Налоги #Начисления Арендной платы #Новый Массив #Обмен между базами #Обновления #Общие ознакомительные рассылки #Операции в 1С #Оптимизация #Организация #Отпуск #Отчетность #Отчеты в 1С #Оформление перевода работника #Оценка задач #Параметр «Количество» #Партнер #Передача неисключительных прав #Перенос данных #Перенос цен из Excel в 1С #Периодичность ДЕНЬ #Периодичность МЕСЯЦ #Печатная форма документа #Планирование #Поле Ввода Значение Субконто #Полезные обработки #Пользовательский режим #Правила обмена #предопределенные элементы справочников #Прием на работу #Принцип работы 1С #Проводки 1С #Программа 1С #Программирование в 1С #Программные права #Продажа ТМЦ #Продажи #Продление #Производство #Просмотр #Путь к файлу #Работа с объектами в 1С #Расторжение #Расчет зарплаты #Расчетные документы #Расширение конфигурации #Регламентированная отчетность #Режим РИБ #Результаты поиска #РСБУ #С # #Сдельный заработок #СЗВ-СТАЖ #СКД #Соединение COM в 1С платформе #Соединение СОМ в 1С платформе #Сравнение конфигураций #Счет-фактура #Текущая Строка #Территориальная привязка #Территориальные рамки #Тестирование 1С #Техническое задание #Типы данных ссылки #Торговое оборудование #Транспортная логистика #Управление проектами #Установка цен номенклатуры #Финансовый учет #Формат MicrosoftExcel #Функционал МРМ #Х-точка #Характеристики Товаров #Хранилище настроек #Хранить историю изменений #Ценообразование #Чтение #Экзамен 1С #электронные подписи #Яндекс-диск или Google-диск #Яндекс.Касса 1С под Linux 1С:УНФ Email или телефон Работа с объектами в 1С Функциональные опции в 1С
Услуги программиста 1С
Получите специалиста  
для решения всех задач
в области 1С
Программы 1С
Цены и подробное описание программ 1С:Предприятие 8.