eTOMомания

Большой ажиотаж в среде российской Telco-индустрии вокруг eTOM, COBIT, etc сильно напоминает аналогичную ситуацию конца прошлого века с “лучшими практиками”, заложенными в отраслевые референтные модели крупных разработчиков ПО для рынка ERP-систем.

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

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

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

  • Формирование стратегии/стратегических инициатив.
  • Выделение ключевых бизнес-процессов.
  • Разработка моделей выделенных бизнес-процессов (AS IS).
  • Анализ соответствия моделей бизнес-процессов требованиям со стороны:
    • Стратегии/стратегических инициатив.
    • Лучших отраслевых практик (eTOM).
    • Других ограничений и стандартов(SOX, COBIT, etc.)

  • Принятие решений по внесению изменений в бизнес-процессы/внедрение новых бизнес-процессов.
  • Разработка моделей перспективных бизнес-процессов (TO BE) по ключевым бизнес-процессам.
  • Разработка реляционных моделей информационных потоков, соответствующих новой модели бизнес-процессов и определение структуры единого информационного поля.
  • Разработка модели трансформации системы и плана потоков работ по управлению изменениями.
  • Управление изменениями и стабилизация.

Слишком глобально, чересчур долго? Впрочем, здесь тоже можно найти вполне эффективные компромиссы.

НЕ ПРОПУСТІТЬ:
Приєднуйтесь до професіоналів e-learning! На I Всеукраїнській конференції дистанційного навчання Ви дізнаєтеся про останні тренди та розробки в галузі навчання, зможете впровадити e-learning у компанії.
Детальніше →

Опубліковано Категорії Управлінський інструментарій
  • Олександр Саврук

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

    После "формирования стратегии/стратегических инициатив", в данном случае, происходит "переосмысление" бизнеса, т.е. переопределение стратегической идеи бизнеса с учетом его перспектив, как минимум, на ближайшие 5-10 лет.

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

    Поэтому, следующим этапом моделируются модели стратегического уровня TO-BE, с последующей д

  • Анонімний

    Совершенно точно, что никакая глубокая аналитика AS IS не нужна. В том смысле, что она никак не должна влиять на представление о перспективной системе управления. Необходимость в разработке базы знаний AS IS имеет одну основную цель – с минимальными рисками спланировать переход к TO BE.
    Начинать "По Хаммеру" – с "чистого листа" – это слишком опасно и скорее всего в большинстве случаев неприменимо. Особенно в отсутствии зрелого и единого понимания, которое обычно отсутствует в начале проектов масштабных преобразований.
    Со всем остальным – согласен.
    Но пост был не о подходах к реинжинирингу вообще, а о наболевшем.:)
    А именно о том, что выбирать в качестве отправной точки какую-либо отраслевую библиотеку, без определения стратегии и наличия достаточных знаний о существующей функциональной структуре – это утопия. Но, судя, по моей практике, утопия переживает очередной виток популярности.
    Мои опасения, что комментарии будут на украинско