Метасценарий зарождения проекта внедрения ERP-системы
(методика подготовительного этапа)

Пытаясь осмыслить, почему так мало внедрений ERP-систем в СНГ и почему столь много неуспешных проектов как в СНГ, так и мире, автор пришел к заключению, что существует только один сценарий развития событий, ведущий от зарождения проекта к успешному внедрению, и именно отклонения от этого сценария мешают появлению успешных ERP-проектов и обуславливают на неуспех идущие проекты. Желая хотя бы в малом поспособствовать укреплению ERP-бизнеса, автор решил изложить данный сценарий в краткой форме на простом неспециализированном языке, дабы сделать его максимально простым для использования представителями бизнеса.

Как известно, для использования ERP-системы необходимо «лишь» 1) «притереть» её к конкретным особенностям бизнеса и 2) создать техническую и организационную среду её эксплуатации. В зависимости от специфики бизнеса, одни ERP-системы притираются лучше (легче), другие – хуже (дороже). После притирки какие-то ERP-системы дают большие возможности, другие – меньшие. Чтобы выбрать максимально притираемую систему и получить от неё максимальные преимущества, оставаясь в рамках бюджета, необходимо следовать некоторой методике. Описание этой методики и составляет содержание нижеприведенного метасценария.

Внутри организации должен сам собою выявиться человек, демонстрирующий:

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

Назовем этого человека бизнес-экспертом. Возможно, в разных бизнес-областях организации выявятся разные бизнес-эксперты.

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

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

Назовем такого человека бизнес-руководителем.

Бизнес-руководитель приходит к мысли об использовании ERP-системы либо общаясь с бизнес-экспертом, либо сам им являясь. Придти к этой мысли он может разными путями:

1. уверившись, что в аналогичной организации успешно используются информационные технологии, и, в частности, ERP-система (успехам неаналогичных организаций он не верит);
2. поскольку его так учили, и он считает, что применение ERP-систем есть один из стандартных приемов менеджмента;
3. потому что ему надоело решать одни и те же проблемы с управлением, и он откуда-то узнал, что внедрение ERP-системы – один из способов коренного решения этих проблем.

Бизнес-руководитель должен изыскать бюджет на реформирование управления «своим» бизнесом (своим аспектом или своим подразделением, или всем бизнесом, если он – высший руководитель). Размер бюджета должен соответствовать получению тех преимуществ, которые он планирует получить в результате использования информационных технологий.

Изыскивая бюджет, бизнес-руководитель должен убедить владельцев бизнеса в том, что реформирование принесёт им дополнительную прибыль или позволит в будущем сохранить бизнес (второй довод – хуже, но – реальнее). При убеждении используются два основных хода:

1. владельцы доверяют авторитету бизнес-руководителя и потому соглашаются;
2. владельцы доверяют, но проверяют аргументы бизнес-руководителя и потом соглашаются.

Естественна ситуация (особенно для России), когда бизнес-руководитель одновременно является и (со)владельцем бизнеса.

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

1. быть в курсе всех проектных решений;
2. отслеживать выполнение плана и бюджета;
3. обсуждать с группой проекта варианты и принимать решения, касающиеся изменения бизнес-процедур и бизнес-структуры;
4. выделять ресурсы организации для участия в проекте;
5. решать орг.вопросы, связанные с проектом;
6. согласовывать с другими руководителями организации изменения в бизнесе, связанные с внедрением системы;
7. внедрять изменения в бизнес по принятым в организации стандартам.

Назовем такого человека – внутренний руководитель проекта. Выполнение функций внутреннего руководителя проекта возможно в двух вариантах.

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

В случае, если принципиально невозможна передача функций бизнес-руководителя другому руководителю, возможно компромиссное решение, когда бизнес-руководитель привлекает себе помощника, и они оба коллегиально выполняют функции внутреннего руководителя проекта. Помощник, как минимум, должен 1) проводить подготовительную проработку вопросов (сбор информации, предварительный отбор вариантов, подготовка документов и т.п.) и 2) мониторинг выполнения решений (отслеживание исполнения приказов, соблюдение планов и бюджета, и т.п.). Крайне желательно, чтобы помощник был в состоянии самостоятельно решать все оперативные, «технические» вопросы по проекту. Чем лучше помощник разбирается в бизнесе и ИТ, тем меньше «мелочных» вопросов придется решать бизнес-руководителю.

Необходимо понимать, что вариант «коллегиального» внутреннего руководителя проекта уменьшает качество проектных решений и увеличивает время их принятия за счет «промежуточного звена». Применение обоих вариантов одновременно, напротив, даёт положительный результат.

Внутренний руководитель проекта должен привлечь специалиста по использованию ERP-систем в специфических для организации бизнес-процессах (назовем такого человека бизнес-аналитиком). Для произвольно взятой бизнес-области, такого человека найти трудно (по крайней мере, автору известно, что в СНГ они ещё не сложились). На худой конец, можно привлечь бизнес-аналитика (это может быть и небольшая группа), специализирующегося на бизнес-процессах сходного профиля; при этом его профессиональные данные должны гарантировать, что он человек быстро-обучающийся, т.к. пока он не освоит специфику бизнеса организации – польза от него будет ограниченная.

Бизнес-аналитика можно привлечь на работу как частное лицо (показавшее свой профессионализм в другой организации) или нанять у фирмы, специализирующейся на применении ERP-систем. Первое – дешевле, но труднее найти правильного человека; второе – дороже, но меньше забот и риска.

Бизнес-эксперт и бизнес-аналитик должны поработать вместе и выработать понимание:

1. ЧТО надо улучшать в бизнес-процессах организации (в, частности, в управлении ими),
2. КАК это можно улучшить с помощью внедрения ERP-системы,
3. ЧТО это улучшение даст организации (количественно и качественно).

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

Для выработки ЧТО-КАК-ЧТО существуют специальные методики, облегчающие этот процесс. Владение такими методиками – одно из проф.качеств бизнес-аналитика.

В процессе работы над ЧТО-КАК-ЧТО, должна частично сформироваться, частично - быть намечена, группа людей внутри организации, которые примут участие в дальнейшей реализации проекта (однозначно, в группу проекта входит: внутренний руководитель проекта, бизнес-эксперт и бизнес-аналитик).

Под конкретный бюджет (определенный – пусть качественно - получаемыми организацией преимуществами) и под конкретные ЧТО-КАК-ЧТО группой проекта должны быть проведены переговоры с производителями ERP-систем на предмет выяснения, может ли их реализация ERP-системы покрыть потребности организации с учетом конкретного бюджета.

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

В ходе переговоров группа проекта, и в особенности - бизнес-аналитик, должна перепроверить достоверность предложений производителей (не всегда предложения – даже производителей – подготавливаются адекватно грамотными специалистами). Для этого анализируется, какими конкретными возможностями конкретной ERP-системы будут реализованы конкретные потребности организации.

Скорее всего, в ходе переговоров выявится несколько ERP-систем, удовлетворяющих потребности организации.

Параллельно с выбором ERP-системы группой проекта должно быть проработано, какие сопровождающие подпроекты должны быть выполнены для полноценного внедрения ERP-системы. Это может быть:

1. бизнес-обучение (как правило, руководящего состава),
2. специализированное технологическое обучение (как правило, прикладных специалистов),
3. построение технологических инфраструктурных элементов (корпоративная сеть, смена «железа», сервера системы и т.п.),
4. консалтинг по проблемам в области, где планируется внедрение ERP-системы, но по специализированным вопросам, не решаемым ERP-системой (оптимизация технологических процессов, налогообложения, внедрение электронных платежей, автоматизация технологических линий и т.п.).

При проработке подпроектов в состав группы проекта должны быть включены соответствующие руководители (HR-менеджер, IT-менеджер и т.д. по курируемой специфике; назовем их - спец.руководители). Исполнение подпроектов должно быть поручено спец.руководителям. Бюджет проекта должен быть скорректирован с учетом сопровождающих подпроектов.

При планировании сопровождающих подпроектов необходимо стремиться к максимально многоцелевому использованию результатов этих подпроектов, т.е. в задачи подпроекта необходимо заносить не только поддержку функционирования (внедрения) ERP-системы, но и достижение других прикладные целей (качественная телеком.сеть позволит не только функционировать ERP-системе, но и эффективно использовать другие корпоративные приложения; обученные специалисты не только смогут эксплуатировать ERP-систему, но и будут лучше выполнять другие свои обязанности, и т.д.). Соответственно, бюджет сопровождающих подпроектов может не только «откусить» часть бюджета проекта внедрения ERP-системы, но и пополнить его, поскольку соответствующие специализированные бюджеты уже могли быть предусмотрены.

Под конкретный бюджет, конкретные потребности и конкретные ERP-системы внутренний руководитель проекта должен привлечь руководителя проекта по качеству, т.е. человека, обладающего

1. лидерскими качествами,
2. аналитическим складом ума,

и владеющего:

3. методикой управления проектами,
4. методикой внедрения ERP-систем,
5. спецификой конкретной ERP-системы.

Основные обязанности руководителя проекта по качеству:

1. контроль над соблюдением процедур управления проектом;
2. привлечение ERP-специалистов (см.ниже);
3. распределение работ по ERP-специалистам, мониторинг исполнения заданий;
4. консультирование внутреннего руководителя проекта по всем вопросам, связанным с проектом;

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

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

Внутренний руководитель проекта и руководитель проекта по качеству совместно руководят проектом, разделяя функции по следующему принципу:

1. внутренний руководитель проекта управляет всеми аспектами проекта, касающимися бизнеса предприятия и ресурсов предприятия;
2. руководитель проекта по качеству управляет всеми аспектами проекта, касающимися работ ERP-специалистов, соблюдения методики управления проектом и методики внедрения.

Руководители проекта совместно должны составить предварительный план проекта и план привлечения ресурсов. В плане проекта должны быть указаны все подпроекты, их взаимосвязь, ориентировочные сроки и ответственные лица. В плане привлечения ресурсов по каждому подпроекту должны быть указаны основные группы задач, необходимые для их выполнения ресурсы, ориентировочные сроки. План привлечения ресурсов по основному подпроекту (собственно внедрения ERP-системы) составляют руководители проекта, по сопровождающим подпроектам – спец.руководители.

Основная цель составления планов – определиться:

1. какие ресурсы необходимы для проекта,
2. откуда их привлекать,
3. как будет распределен бюджет,
4. какие планируются сроки и контрольные точки.

Максимальный объем мат.-тех. ресурсов (помещения, связь, техника, расходные материалы, …) должен быть привлечен «изнутри» организации. Приобретение возможно с учетом дальнейшего (после окончания проекта) использования.

Человеческие ресурсы должны быть спланированы таким образом, чтобы привлечь «со стороны» только специфические ресурсы, наличие которых не характерно для организации. Максимальный объем человеческих ресурсов должен быть привлечен

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

Назовем человеческие ресурсы, привлекаемые со стороны, ERP-специалистами, а привлекаемые из штата организации – внутренними специалистами.

Руководитель проекта по качеству должен донести основные принципы методики внедрения (состав и последовательность ключевых задач) и методики управления проектом (как будет составляться отчетность, происходить контроль над ходом проекта, привлекаться ресурсы и т.п.) до ключевых лиц группы проекта. Планы и методики должны быть согласованы с бизнес-экспертом, бизнес-аналитиком, спец.руководителями (по их специфике) и утверждены внутренним руководителем проекта.

Руководитель проекта по качеству должен определить источник привлечения ERP-специалистов для основного подпроекта, а спец.руководители – спец.ресурсов для сопровождающих подпроектов.

Если руководитель проекта по качеству привлечен из специализирующейся на внедрении ERP-систем фирмы, то источником ERP-специалистов закономерно будет выступать эта фирма. В этом случае существенно уменьшаются риски (потенциальные проблемы), связанные с квалификацией и психологической совместимостью участников группы проекта, поскольку руководитель проекта по качеству хорошо знает «своих» людей.

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

Начинается реализация собственно проекта внедрения ERP-системы и сопутствующих проектов.

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

Весь описанный метасценарий верен не только для внедрения ERP-систем, но и для любого бизнес-проекта, требующего существенного бизнес-реинжиниринга. Ставьте вместо выражения «информационные технологии» другие «Х-технологии», вместо «ERP-система» название частной бизнес-технологии внутри Х-технологии типа «X-система», и получите совершенно адекватный метасценарий по другой специфике.

Полезно понимать, что существует еще другой тип проектов, которые часто путают с бизнес-проектами. Это – внедрение в бизнес внешне-наработанных, стандартных для отрасли приемов, методик, технологий. Назовем такое внедрение – технологическим проектом. Для того, чтобы внедрять технологические проекты, придерживаться приведенного метасценария нет необходимости, потому что основные ЧТО-КАК-ЧТО уже известны, достаточно провести конкретный расчет для организации и соблюдать план-график работ.

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

Кстати, внедрение автоматизированных систем налогового и базового финансового (бухгалтерского) учета больше относится к технологическим проектам. Из-за неправильного классифицирования этих проектов как бизнес-проектов, часто объявляют об успешном внедрении ERP-системы, хотя реально внедрение происходило только, например, в сфере базового финансового учета.

Давайте теперь разберем, к чему приводят «типовые» отклонения от описанного метасценария при зарождении бизнес-проектов.

Зачастую, подготовительный этап проекта проводится неполноценно; и внедрение начинается сразу с привлечения фирмы, специализирующейся на внедрении ERP-систем. Тогда, если организация и фирма-внедренец (предоставляющая бизнес-аналитика, руководителя проекта, ERP-специалистов) относятся к делу ответственно, то основные ЧТО-КАК-ЧТО вырабатываются уже в ходе внедрения. В таких случаях, на момент, когда весь проект должен уже закончиться, только-только становится понятно, как его начинать (заканчивается подготовительный этап). Если находится дополнительный бюджет (и время), то всё, в конце-концов, складывается успешно для организации (и согласно нашего метасценария). Если – нет, то внедрение даёт успешный результат только в типовых бизнес-процессах (т.е. в части, где проект – технологический).

Часто функции бизнес-аналитика выполняет внутренний специалист «из смежной области», например айтишник. Когда дело доходит до этапа внедрения, все ляпы по бизнесу начинают вылезать и проект либо стопорится (если на соблюдении целей, поставленных айтишником, формально настаивается), либо возвращается к подготовительной стадии с произвольным изменением бюджета и сроков. Если дополнительный бюджет (и время) находится, то всё, в конце-концов, складывается успешно для организации (и согласно нашего сценария).

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

Зачастую принципы методики внедрения и методики управления проектом не доводятся до ключевых лиц группы проекта (со стороны организации). В этом случае, никто, кроме руководителя проекта по качеству, не понимает, на какой стадии находится проект и в чем «суть момента». Это даёт возможность ERP-специалистам и самому руководителю проекта по качеству скрывать свои неквалифицированные действия и «проедать» бюджет.

В процессе выбора ERP-системы производители (а того пуще – продавцы) ERP-систем часто указывают соответствие своей системы всем мыслимым и немыслимым требованиям бизнеса, когда, на самом деле, такого соответствия не существует (или оно требует доработок системы). Формальная проверка заявлений производителей группой проекта не производится (даже поверхностная). Это, естественно, приводит к тому, что проблемы всплывают уже в ходе проекта, когда «уже поздно» менять систему, и влечет за собой увеличение бюджета (времени) проекта на существенную незапланированную доработку системы, либо часть требований остаётся неудовлетворенной (что, кстати, может быть и положительно, если требования были надуманными).

Случается, что, непрофессиональный бизнес-аналитик слишком «заужает» требования к системе, не учитывая перестройку бизнес-процессов при использовании системы. Также, случается, что бизнес-аналитик слишком «завышает» требования к системе, желая получить максимальный эффект от внедрения системы, не разделяя требования на действительно важные для бизнеса и «желаемые». Всё это приводит к тому, что серьезные производители (или ERP-специалисты) либо вообще не подают свои предложения, либо честно выставляют за удовлетворение «накрученных» требований высокую цену. Если группа проекта (и, в частности, внутренний руководитель проекта) не воспринимает этот сигнал и не инициирует пересмотр «надуманных» требований или повышение бюджета, то закономерно «проходит» предложение фирмы, обещающей «всё и недорого», что приводит к развитию событий согласно предыдущему пункту.

В целях исследования верности приведенного сценария может быть сформулировано еще множество других отклонений. Чуть ли не каждый абзац метасценария даёт своё собственноё типовое отклонение…

Безусловно, надо учитывать, что метасценарий не претендует на описание всех вариантов развития событий по зарождению проекта внедрения ERP-системы. Он демонстрирует смысловое наполнение, «дух» событий и их логическую взаимосвязь, но «по букве» история может развиваться и иначе: некоторые пункты могут разбиваться, сливаться или даже меняться местами; указанные роли могут выполняться группой людей или одним человеком – за десятерых; могут появляться параллельные процессы и т.д.

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

Автор надеется, что, не смотря на столь краткое изложение столь важного вопроса (разные аспекты которого описаны во многих больших статьях, а то и книгах), именно краткость и простота языка облегчат использование приведенного метасценария представителями бизнеса. Напоследок, автор призывает реальных экспертов, заинтересованных в долгосрочном развитии ERP-бизнеса, внести свои корректировки в метасценарий и присоединиться к его «насаждению в практику».