ERP Особенности национального внедрения или деваться некуда – надо внедрять
14.11.07
При внедрении системы управления предприятием следует выделить несколько дисциплин, являющихся фундаментом для построения и разработки успешной системы управления производством. Рассмотрим рекомендации.
Начало темы
ИТ отдел и ИТ инфраструктура на предприятии должны быть готовы к развертыванию системы технически, организационно и служить опорой для проектной группы внедрения, как наиболее восприимчивая к изменениям часть коллектива. Как определить готовность ИТ службы?
Например, ответить на следующие вопросы:
1. Развернута ли служба HelpDesk? Написана ли и утверждена ли процедура, регулирующая ее работу? Подобная служба может функционировать и без использования современных ИТ, но лучше, если ее работа будет поддержана каким-либо программным продуктом.
Процедура, регулирующая ее работу должна включать как минимум:
• описание структуры службы;
• типы инцидентов и их значимость для бизнеса;
• максимальное время реакции;
• максимальное время решения инцидента;
• порядок регистрации инцидента;
• порядок реакции на инцидент;
• обязанности службы HelpDesk и остальных специалистов ИТ, привлекаемых для разрешения инцидентов;
• порядок и периодичность пересмотра процедуры.
Создание такой службы дает:
• руководству компании - определенную опору для оценки и дальнейшего развития ИТ, а также некоторые управляемые критерии качества предоставляемых ИТ-услуг;
• персоналу компании - единую точку обращения за помощью и уверенность, что проблема будет решена в заданное время.
2. Существует ли, и как обновляется документация на информационные технологии, включая, как минимум:
• документацию на сеть: логическую схему сети с планом адресации и маршрутизации, топологию с привязкой к плану здания, спецификацию активного и пассивного оборудования, конфигурации активного оборудования, пароли и порядок доступа к активному оборудованию, наличие и описание внешних линий связи, телефоны и контактные лица провайдеров и поставщиков оборудования, используемого в сети, система разграничения прав, имена или должности ИТ-специалистов, отвечающих за сеть (информация для второй линии HelpDesk);
• документацию на сетевые сервисы – файловые, серверы печати и пр. по такому же принципу, что и для сети;
• документацию на конфигурацию рабочих станций – по такому же принципу, что и для сети;
• документацию на бизнес-приложения: список приложений с перечнем потребителей, имена или должности ИТ-специалистов, отвечающих за каждое из них (информация для второй линии HelpDesk), контакты поставщиков;
• порядок пересмотра документации (кто и с какой периодичностью имеет право и должен вносить изменения).
Создание документации и управление имениями в конфигурации дает:
• руководству и персоналу компании - уверенность, что ИТ-инфраструктура стабильна и управляема;
• специалистам HelpDesk - контакты лиц, способных решить соответствующую проблему;
• ИТ-специалистам - упрощение поиска неисправностей и разграничение зон ответственности.
3. Существует ли процедура управления изменениями? Эта процедура описывает отдельно процессы внесения изменений в конфигурацию сети, настройки рабочих станций, сетевых сервисов и бизнес-приложений. Причем, в последнем случае «отдельно» - может означать наличие отдельной процедуры для каждого бизнес приложения.
Описание включает, но не ограничивается следующим:
• кто имеет право инициировать изменения;
• порядок согласования изменений (оценка стоимости, времени, требуемых ресурсов и влияния на качество);
• кто и как проводит (возможно, сначала в специально созданном тестовом окружении) изменения;
• как проводится тестирование изменений;
• кто и как протоколирует изменения (для последующего внесения в документацию);
• порядок оповещения пользователей и внешних поставщиков услуг.
Наличие процедуры управления изменениями дает:
• руководству компании - возможность планировать снижение производительности, связанное с внесением изменений; определенную уверенность, что изменения будут полезными для всего предприятия; возможность рассчитать (хотя бы приблизительно) затраты, связанные с внесением изменений;
• персоналу компании - возможность планировать работу с учетом возможного отсутствия того или иного ИТ-сервиса;
4. Существует и выполняется ли процедура действий во внештатных ситуациях? Имеется в виду подготовка к действиям и порядок действий во внештатных ситуациях, включая:
• порядок создания, периодичности и хранения резервных копий конфигураций;
• порядок создания, периодичности и хранения резервных копий данных;
• наличие и описание резервирования оборудования и программного обеспечения;
• классификацию внештатных ситуаций. Например, затрагивает только одно или несколько рабочих мест, затрагивает отдел, затрагивает предприятие целиком;
• порядок восстановления конфигураций и данных при каждом виде внештатной ситуации;
• время на восстановление при каждом виде внештатной ситуации;
• список контактов для обращения в случае внештатных ситуаций.
Наличие процедуры дает:
• руководству компании - определенную уверенность в защищенности предприятия от потери информации, оценку затрат и времени на восстановление работоспособности;
• персоналу компании - порядок действий во внештатной ситуации.
Прежде, чем переходить к следующим шагам, важно, чтобы технология в таком виде «поработала» некоторое время и показала свою жизнеспособность в рамках данного конкретного предприятия. Попытка формального подхода в последствии может вылиться в дополнительные затраты и, возможно, приведет к полной неработоспособности системы управления предприятием.
Цель автоматизации системы управления предприятием. Что дальше? Дальше можно остановиться. Потому что исправно работающая служба ИТ ценна сама по себе. Если же назрела необходимость чего-то большего, то нужно ответить на главный вопрос: «Зачем? Какой цели мы хотим достичь?». Трудно не согласиться с тем, что неверно определенная цель, размытая или постоянно меняющаяся, не может привести к успеху. С самого начала этого материала мы пытались показать, что система управления производством – это, в первую очередь, инструмент руководства предприятием. От того, насколько руководители четко представляют себе чего они хотят, каких изменений в своей работе желают добиться, , зависит, насколько точно будет сформулирована цель. Трудно что-либо предложить руководителю, который просит «сделайте мне хорошо», не представляя, что для него это «хорошо».
Возможно, на предприятии уже есть служба контроллинга или кто-то выполняет функции контроллера. Это хороший источник помощи при определении цели автоматизации управления. ИТ-отдел может быть другим источником. Третьим источником помощи может быть внешний консультант. Цель внедрения новой системы управления должна согласовываться со стратегической целью бизнеса. Если она не определена и не закреплена на бумаге, если она неизвестна всем работникам предприятия или, если сам этот текст не вызывает понимающего кивка, то стоит отступить на один шаг. Предприятие явно не готово. Начинать нужно с обучения руководящего персонала и только потом возвращаться к вопросу автоматизации системы управления.
Заказчик. Когда цель сформулирована, важно определить «генерального заказчика». В литературе и на практике это лицо (или группа лиц) называют по-разному: заказчик, спонсор и т.п. В любом случае речь идет о лице, которое своим авторитетом, положением и решениями будет поддерживать внедрение. Заказчик должен иметь право распоряжаться всеми видами необходимых ресурсов и предоставлять их в распоряжение проектной группы (о проектном подходе будет сказано ниже). Цели внедрения автоматизации управления – это цели заказчика. Заказчик инициирует проект и он же может его свернуть, если внедрение серьезно отклонилось от цели. Вовремя остановленный проект тоже можно считать успешным, так как мы лучше поняли свои цели и не потратили слишком много средств впустую. При этом заказчик – это не руководитель проекта, он клиент, главный потребитель результатов. Заказчик не должен вмешиваться в оперативную работу проектной группы, но выступать конечной инстанцией при решении возможных конфликтов.
Коллектив предприятия. Другим предварительным условием является подготовка коллектива к изменениям. Люди по своей природе консервативны и не любят быстрых изменений в их ближайшем окружении. Изменение системы управления предприятием затронет каждого на его рабочем месте. Важно внятно объяснить цель изменений, «создать критическую массу» среди персонала. Простыми административными методами этого не решить.
История развития промышленности уже знает примеры, когда изменялись методы производства и приемы управления. Лучше не повторять ошибок предшественников и не получить «восстание луддитов» в рамках отдельно взятого предприятия. Внедрение системы управления предприятием меняет значимость отдельных профессий. Роль части из них уменьшается, а роль других, наоборот, увеличивается с повышением требований к квалификации. Так было и при внедрении мануфактур, парового привода, электричества и т.д. Следует понимать, что квалифицированные кадры - это тоже ресурс предприятия и его потеря ведет к убыткам. Всегда дешевле переобучить специалиста из смежной области, чем воспитать нового с нуля.
Это изменяет роль традиционных отделов кадров, функции которых обычно сводятся к оформлению приема/увольнения и другим регистрационным действиям. При изменении системы управления, отдел кадров становится «политуправлением», «школой» и «средством массовой информации» одновременно. На него возлагаются дополнительные функции по разработке и внедрению систем стимулирования, программ обучения и переобучения, отслеживания тенденций в коллективе и помощь в выработке корректирующих действий.
Дилемма. Теперь, когда у нас есть поставленная цель, мотивированный коллектив, руководящий состав предприятия, работающая служба ИТ, можно снова задать себе тот же вопрос: «нужна ли автоматизированная система управления предприятием?». Возможно, в процессе подготовки узкие места управления уже нашли свое решение? A средства, зарезервированные на решение «ERP-вопроса», лучше потратить с толком в другом месте?
Если ответ: «Да».
Управление проектами. Один из наиболее разработанных и формализованных подходов к внедрению - это проектный подход. Поэтому, если даже предприятие не применяет проектный подход в основной деятельности, то организация проекта по внедрению системы управления производством вполне оправдана. Здесь сразу следует предостеречь от часто встречающейся ошибки – это проект предприятия и для предприятия, хотя, возможно, и выполняемый совместно со сторонними консультантами. На самом деле, осознаем мы это или нет, проект начался, когда мы задумались об улучшении системы управления. То есть задолго до того как пришли к решению об автоматизации. Если весь процесс усовершенствования системы управления предприятием начинался как проект реинжиниринга, то внедрение автоматизированной системы будет либо его частью, либо подпроектом, и имеет гораздо больше шансов на успех.
Остерегайтесь, когда проект внедрения системы управления полностью разрабатывает компания, победившая в тендере на поставку и «внедрение» ПО.
Этот проект, как правило, отражает цели, которые ставит перед собой компания-поставщик. Эти цели во многом могут не коррелировать с целями предприятия.
На тему управления проектами написана масса книг и статей. Остановимся на наиболее важных, на наш взгляд моментах.
Разработка требований. Разработка требований должна быть выполнена до выбора конкретного программного продукта. Требования, изложенные в письменном виде, помогают гарантировать, что функциональность системы определяется пользователем, а не программистом. Внимание к требованиям позволяет свести к минимуму изменения системы после начала внедрения. Обнаружив ошибку в реализации одного из бизнес-процессов, понадобится исправить несколько строк кода. Если же в процессе работы обнаружится ошибка в требованиях, придется изменять проект или даже отказаться от его части.
Это очень щепетильный момент, потому что он затрагивает такую тему, как «уникальные и сложные бизнес-процессы». На наш взгляд, это крайне субъективная точка зрения «родителя» (руководителя) на «ребенка» (предприятие). «Мой ребенок» всегда самый «уникальный и/или сложный». Если это так, то мы снова возвращаемся к вопросу о целях. Если целью внедрения ставится только ускорение операций, то ответ лежит в автоматизации «узкого» места. Система уровня управления предприятием в этом случае будет «стрельбой из пушки по воробьям». Обладает ли предприятие некими уникальными know-how в области управления, однозначно выяснится на этапе формализации бизнес-процессов при подготовке требований. А не «выплеснуть ребенка вместе с водой» поможет процедура контроля изменений.
В последнее время появились новые средства проектирования и моделирования бизнес-процессов, которые сближают позиции бизнес-аналитиков и программистов. Использование таких средств может существенно облегчить документирование и проектирование бизнес-процессов предприятия. Эти инструменты создают модели, как правило, независящие от конкретной платформы, и, обладающие самостоятельной ценностью в качестве знаний о работе предприятия.
Определение рисков. Изначально риски могут быть определены в общем виде, например:
• риск модификации требований;
• риск невыполнения расписания;
• риск высокой текучести кадров.
По мере продвижения риски должны пересматриваться и уточняться. Не идентифицированный риск представляет наибольшую угрозу проекту. Часть рисков может быть снята действиями, предпринятыми согласно планам управления рисками.
Часть может появиться при уточнении требований, например:
• используемые системы САПР выдают спецификации в формате, не совместимом с данными, используемыми при посменном планировании;
• формат электронной документации, передаваемой подрядчиками, не совместим со стандартами используемой системы CRM;
• учетная информация не содержит сведений, необходимых для фискальных отчетов.
Такой подход позволит организовать управление рисками. В управление рисками включаются:
• описанная выше процедура периодического пересмотра рисков;
• оценка стоимости рисков;
• разработка детальных планов по устранению рисков (включая необходимые для устранения ресурсы);
• создание анонимного канала для уведомления о рисках.
Так как весь процесс внедрения системы управления более человеко-ориентированный, чем машинно-ориентированный процесс, с самого начала следует обратить внимание на риск, связанный с недостаточной квалификацией специалистов проектной группы и на рабочих местах. Для управления этим риском необходимо разработать учебные планы, выделить средства и время для обучения. И провести обучение как можно раньше. Таким образом, можно решить две задачи: собственно, снизить риск недостаточной квалификации и привлечь на «свою сторону» больше специалистов.
Другой риск, часто упускаемый из виду – это риск ухода ведущих специалистов занимавшихся внедрением. Фактически с их уходом теряется часть выстроенной новой системы управления, смысл которой быть гибким инструментом и эту гибкость ей придают люди.
Контроль изменений. Проект - это не строгое движение по прямой. Это - систематический управляемый процесс оценки и пересмотра требований, рисков, сроков, ресурсов. Контроль изменений регламентирует: с какой периодичностью, кем и как вносятся изменения в требования, риски, сроки и ресурсы проекта. Приниматься могут не все изменения. Процедура должна регламентировать порядок внесения и «защиты» изменения инициатором. А также порядок и сроки рецензирования заявленного изменения. Для изменений, касающихся состава, функциональности программного обеспечения, кода программы или других технологических аспектов, должна быть предусмотрена соответствующая процедура тестирования.
Наблюдаемость проекта. Все материалы по проекту должны быть свободно доступны всем участникам проекта. Для каждого этапа должны быть выработаны простые, измеряемые критерием «да/нет» параметры прогресса. Их удобно свести в одну таблицу, которую видят все.
Другая таблица может отражать процесс слежения за ошибками. А соответствующая процедура проекта регламентировать порядок регистрации, назначения ответственного и отслеживание статуса ошибок.
Заключение. Внедрение новых технологий - всегда зыбкая почва. Невозможно держать в памяти и манипулировать фактами и методами из огромного моря литературы, публикаций и мнений. Авторы постарались наметить для себя базовую линию. Предполагаем, что материал может быть полезен как ИТ специалистам, так и руководителям, решающим для себя вопрос выбора и внедрения системы управления предприятием. Авторы надеются, что он вызовет полемику, которая позволит скорректировать или изменить подход и отношение к проблеме внедрения ERP.
Авторы:
А.А. Породько
А.В. Ишуков
https://www.lobanov-logist.ru/library/all_articles/55348/
ERPNEWS©
Литература:
Николас Дж. Карр «Блеск и нищета информационных технологий»
Стив Макконнелл «Остаться в живых»
Стив Макконнелл «Совершенный код»
А.Дайле «Практика контроллинга»
Учебник MBA «Реинжиниринг бизнес-процессов»