Давайте поговорим про провалы при автоматизации собственными силами.
Про фиаско фирмами-внедренцами поговорим в другой раз, и я расскажу, как на расширенном совещании, где я выступал в роли руководителя проектов со стороны 1С:Франчайзи, признали мою некомпетентность и просили заменить… Приятного мало.
Для начала необходимо определить, что такое провальный проект. Для фирм-франчайзи это измеряется недополученной прибылью или убытком, в то время как на предприятии, где нет финансовых показателей, это сроки запуска и уровень доверия между заказчиком/спонсором и руководителем проекта. После дед-лайна, как правило, этот уровень экспоненциально падает.
Итак, мои наблюдения. Повторюсь, внедрения сторонними силами (1С Франчайзи) мы не рассматриваем, так как есть отличия в проблемах внедрений собственными силами и подрядчиками. Например, подрядчику важно, чтобы требования и цели проекта менялись как можно меньше в ходе реализации проекта, а меняются они почти всегда и если это не учесть, то можно экономически просчитаться. А ещё занудство приёмщиков работ, неправильно сформулированные критерии приёмки работ…
Возможно приведённые наблюдения вполне ложатся и на провалы 1С Франчайзи. Об этом поговорим в другой раз.
Неправильно подобранная команда или организационная структура проекта.
Посмотрите на оборонительные рубежи Севастополя 1941 года.
Во многих ИТ-отделах нет разделения на линии поддержки [обороны], но организационная структура проекта должна выглядеть как оборона в период войны. На проекте должны быть:
1 линия — сервис-инженеры низкой/средней квалификации для решения вопросов «куда пропала моя база из списка», «где ярлык 1С», «почему разные версии сервера и клиента», то есть технические вопросы, связанные с установкой программного обеспечения и его работоспособностью.
2 линия — консультанты, которые владеют внедряемым программным продуктом. Они должны помочь рядовому пользователю вывести необходимый отчёт, открыть произвольный справочник, продемонстрировать «как закрыть границу редактирования данных», ну и, конечно, показать кнопку «Восстановить положение окна» .
3 линия - бизнес-аналитики, программисты. Специалисты, которые уверенно владеют программой в режиме «Конфигуратор» и/или «Предприятие».
Распространённая ошибка — штат из одних лишь программистов, которые распределены по отделам. Этот программист решает проблемы экономистов, этот — бухгалтерии, а этот — самого главного бухгалтера (и т.д.). Рядовой бухгалтер не должен общаться с программистом в поисках ответа «Где ярлык 1С». Это значительно тормозит процесс разработки, а также несёт экономическую неэффективность. Ведь стоимость часа работы программиста выше сервис-инженера. Для программиста источником задач должен являться план-график и, иногда, руководитель.
Саботаж
Приведу пару абзацев из книги В. Печёрских и Г. Бельцева «Внедрение ERP-решений на платформе «1С:Предприятие 8», которые повторяют мои мысли о саботаже. Кто внедрял — всегда с этим сталкивался. Всегда!
Исчерпывающе написано. Это работает, но в случае НЕвыполнения следующего пункта…
НЕзаинтересованность руководства в проекте.
Почему руководство (спонсор/заказчик проекта) не заинтересовано?
Сложный житейско-коммерческий вопрос… Как мне показалось, я это встречал у управленцев низкой категории, которые полагали, что их вниманию поддаётся лишь коммерция или, ещё хуже, проверка «кто сегодня опоздал», а автоматизация подлежит делегированию, например, директору по ИТ. Отсутствие главного лица на еженедельных совещаниях говорит о том, что возникший спор двух и более подразделений невозможно будет решить.
Например, кто должен будет ввести 10 000 ресурсных спецификаций? Производственный отдел говорил, что согласно плану работ это вводит Технический отдел. Технический отдел показывает на Техническое задание (простите за тавтологию, но это пример из жизни), где сказано, что вводится автоматизировано с помощью доработок программиста. Программист на этот участок ещё не трудоустроен. Тупик! Необходимо волевое решение заставить один или два отдела вводить 10 000 спецификаций.
Если с первых совещаний руководства нет и оно не заинтересовано присутствовать — прекращайте проект.
Неправильная технология внедрения
Первое. Внедрение со слов генерального директора — провал! Хоть он уверенно облокотится на спинку стула и скажет, что уже со слов создал целую современную производственную систему… [Нет, это может быть полной правдой], но риск очень большой. Выгодно соглашаться на такие условия 1С Франчайзи — заплатят много в силу бесконечности проекта, а ответственности никакой.
Второе. В статье «Как начинать автоматизацию предприятий» я приводил свою таблицу выбора технологии внедрений.
Поинты помогут вам в выборе. НО! Вашу аналитическую работу никто не отменяет. Вы должны понимать, что есть виды бизнеса где 5 человек требуют ТКВ. Например, дочернее предприятие крупного холдинга занимающееся сервисом — уборкой территории, общепитом, услугами автотранспорта и т.п. — много бизнес-процессов, требующих описания.
Если вкратце, то технология обязывает:
- вести документацию проекта (начиная обследованием и заканчивая паспортом системы — состав зависит от выбора),
- иметь утверждённый состав работ,
- указывать ответственных лиц и сроки,
- описывать риски и способы минимизации их,
- устанавливать правила согласования изменений и многое другое.
Чтобы правильно определить технологию, требуется квалифицированный специалист. Нет на предприятии? Временно привлеките.
Неправильная концепция проекта
«Телефонизация страны…» Это моё фото (не фотошоп
) сделанное в Брянской области в 2008 г.
Однозначно надо быть профессиональным техническим специалистом (как и в предыдущем пункте), чтобы принять стратегически верное решение в построении концепции проекта. Это включает в себя выбор конфигурации программного обеспечения, серверного оборудования и аппаратных средств, архитектуры базы данных, способ разработки и т.д. Неверный выбор приведёт к провалу и, как правило, в завершающие этапы вроде пуско-наладочных работ. Коллеги, делайте нагрузочное тестирование!
Мне пришлось создавать аналитическую записку про многофирменный учёт в одной базе в момент запуска 1С:УПП в холдинге. Причиной тому стали, помимо транзакционных ошибок СУБД в виде дедлоков и таймаутов, концептуальные ошибки единой НСИ, отсутствие разделения учёта по организациям на многих объектах УПП, отсутствие единого администратора на предприятии. В попытках интегрировать производственные и обслуживающие предприятия система стала нерабочей. Пришлось отказываться от выбранной концепции. Данная ошибка стоила директору ИТ должности, а проект запустили со второй попытки в отдельных базах.
Протоколирование
От хитрости или простого человеческого «забыл» необходимо протоколировать все взаимодействия.
Все совещания (в активной фазе правильно проводить их еженедельно) должны протоколироваться. Если допускает технология, то достаточно в электронном письме всем участникам разослать достигнутые договорённости, ответственных и сроки. Правда лучшее средство — 1С Документооборот или аналог, который обязывает нажать кнопку «Ознакомился», «Принять к исполнению». Не стесняйтесь повторять сказанное и давать указания должностным лицам. Во имя успешного проекта!
Обучили сотрудника — занесите запись в протокол обучения и пусть распишется, даже если у вас приятельские отношения с обучаемым. Настанет тот день, когда сотрудник или даже отдел скажет, что ничего не знают. И по умолчанию виноваты вы (или ИТ-отдел).
Помню в 2007 году занимался автоматизацией комбикормового завода, в частности, дело касалось лаборатории [где происходила оценка принимаемого зерна на сор, клейковину, сорт и другие параметры]. На протяжении нескольких недель были пуско-наладочные работы, обучение, тестирование.
Наступил тот день когда в старой базе было запрещено, а в новой требовалось вводить документы исследований. Вот тут же возникла жестокая битва под названием «Мы не знаем программу! Нас не обучали!». Я достал несколько листов протоколов обучения с подписями обучаемых. Нокаут.
Практически на каждом крупном проекте будут сотрудники, которые случайно или специально забудут.
Политические игры
Выполнение проекта ради похвал от владельцев бизнеса явление нередкое. Хуже когда идёт нездоровая конкуренция за должность и вместо принятия решения идёт политическая война «служебками». Политические интриги сильно бьют по проекту. Увидели политику — выходите! Или включайтесь в борьбу, если тянет.
В заключение…
На самом деле сложно описать все увиденные ошибки на проектах внедрений приводящие к провалу. Кто-то видел другие трудности, в виде слабохарактерности руководителя проектов или прекращения финансирования и готов утверждать что мои — пустяки. В любом случае, проект автоматизации требует бдительности, опыта и ответственности. Это всегда что-то новое, интересное и познавательное. Избегайте провалов!
П.С. Присылайте Ваши наблюдения и опыт на doc@ingraf.su и мы вместе подготовим ещё одну публикацию.
