Объять необъятное

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

С чего начать

Вопрос определения цели создания КИС в той или иной форме решается при разработке стратегии компании или стратегии IT. Но часто цели создания КИС определяются или в общем (без подробностей), или, наоборот, слишком детально, что в свою очередь приводит к ошибкам планирования предстоящих работ.

Внедряемые сегодня IТ-решения уже не являются "средствами выживания", без которых бизнес просто не может существовать. Задачи территориально распределенных компаний (ТРК) при создании КИС продиктованы необходимостью формирования единого информационного пространства, позволяющего повысить оперативность сбора, обмена и обработки объема информации, что может отразиться на повышении инвестиционной привлекательности, сокращении операционных издержек и т. д.

При реализации проектов создания КИС очень часто инициатива отдается IT-службам, как наиболее компетентным в оценке текущего состояния IT и возможных путей их совершенствования. К сожалению, при создании крупных КИС в ТРК такой подход содержит слишком много рисков, и стоимость ошибок может оказаться слишком высокой. С другой стороны, представители бизнеса — спонсоры — действительно не в состоянии взять на себя решение вопросов уровня IT. Как же поступить в таком случае?

Одним из способов является формирование структуры, объединяющей требования бизнеса и возможности исполнителей, что должно стать первым шагом на многотрудном пути создания КИС. Она может существовать в виде координационного совета, проектного комитета, центра компетенции и т. п. Главное требование — подчинение высшему руководству компании и постоянный характер деятельности, по крайней мере, на период осуществления проекта. Координационный совет должен объединить в своей структуре представителей бизнеса, исполнителей и экспертов.

Представители бизнеса в координационном совете — это руководители компании, на деятельности которых должно отразиться внедрение КИС. Они должны определить те показатели, которые станут основанием целесообразности предстоящих работ. Исполнители в составе координационного совета должны представлять службы и подразделения, которые будут отвечать за реализацию конкретных работ по созданию КИС. Они, в свою очередь, оценивают возможные затраты, необходимые для достижения показателей, определенных представителями бизнеса.

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

Описание будущего

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

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

На что следует обратить особое внимание при разработке бизнес-процессов в ТРК?

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

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

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

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

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

С точки зрения последующего практического использования результата описания будущих бизнес-процессов целесообразно организовать обсуждение и приемку результатов совместной командой представителей бизнеса — тех, кто будет работать согласно новым процессам, и исполнителей — тех, кому придется реализовывать новые процессы. В состав исполнителей должны входить не только, консультанты, которые будут настраивать или модифицировать систему, но и представители внутренних служб компании: службы качества, ИТ-службы, HR, службы безопасности и т. п. За счет такой организации приемки результатов описания бизнесов-процессов будет реализован один из важнейших принципов построения проектной команды — единое понимание целей и задач проекта, а также путей их достижения.

Состав и этапы проекта построения территориально распределенной КИС

Перед тем, как приступать к определению цели создания КИС, желательно завершить построение или, как минимум, составление плана построения организационной структуры компании, четко понимать функции и задачи подразделений, цепочки и иерархию принятия решений, уровни реализации различных задач — какие задачи реализуются централизованно, какие — на местах. Если построение ТРК не завершено, то необходимо представлять, на каком этапе находится построение компании и в каком состоянии находится текущий процесс.

На первый взгляд, состав и перечень этапов и работ проекта создания КИС в ТРК мало отличаются от этапов и работ проектов создания КИС в любой другой компании. По большому счету — это так. Разница заключается лишь в объеме операций, ресурсов, затрат и, самое главное, в организации управления. Опыт крупных проектов создания КИС показывает, что ошибки, допущенные при построении управления, являются основной причиной неуспеха проектов — 75 % неудачных проектов связаны с ошибками управления.

Другим существенным отличием проектов построения КИС в ТРК является комплексность. Под комплексностью понимается совокупность нескольких подпроектов, выполнение которых необходимо для построения КИС. Специфика отдельных проектов может существенно различаться по объекту проектной деятельности, подхода к реализации, управлению, ресурсам, бюджетам и т. п. Поэтому группы проектов целесообразно объединять в направления. При этом важно понимать, что реализация проекта построения КИС в ТРК может быть оптимизирована за счет экономии "на объеме", в первую очередь, выделяя те проекты, которые имеет смысл выполнять централизовано, а не для каждого объекта ТРК, объединяя ресурсы для выполнения общих задач и сокращая время.

На примере организации программы внедрения КИС в крупнейшем телекоммуникационном холдинге можно говорить о выделении следующих направлений:

• управление проектом;
• построение технической архитектуры;
• разработка и внедрение прикладных программ;
• создание центров компетенции.

Каждое направление и проекты, входящие в направления, должны пройти традиционный путь, заключающийся в осуществлении набора операций и действий, объединенных в этапы. Условно такие операции и действия объединены в следующие этапы: планирование; анализ; проектирование; разработка; тестирование; переход к эксплуатации.

Таким образом, совокупность всех проектных работ может быть представлена в виде матрицы.

Управление

Управление включает в себя не только комплекстрадиционных мероприятий по управлению проектом, но и решение принципиально важных вопросов, связанных с методологическим его обеспечением, организацией взаимодействия между подпроектами и другими проектами компании, в частности, с проектами организационных преобразований, которые сопровождают внедрение КИС. Этапы работ направления "Управление" носят условный характер, тем не менее, традиционное понимание их очень хорошо позволяет понять также суть и последовательность работ по организации управления. Планирование с точки зрения организации управления наиболее понятный этап, который присущ именно масштабным проектам. На этом этапе осуществляется верхнеуровневое планирование направлений работ по созданию КИС. В том числе, создается мастер-план проекта, основной задачей которого является определение совокупности работ и ключевых проектов, определение ключевых взаимозависимостей и контрольных точек. Одновременно с мастер-планом разрабатывается и утверждается устав проекта, в котором находят свое отражение ключевые положения: цели проекта и пути их достижения.

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

Далее инициируются работы по созданию методологических требований к подпроектам и организации системы управления. Эти работы соответствуют работам фазы "Проектирование". На этом этапе создается проектный офис, в состав которого могут входить группы:

• управление работами — сбор и анализ оперативной отчетности о ходе проекта, формирование отчетов руководству, анализ исполнения мастер-плана проекта, управление коммуникациями и документами;

• управление рисками и проблемами — анализ отклонений от первоначальных планов и параметров, выработка действий, снижающих риски, прогнозирование незапланированных действий и влияний, формирование резервов;

• управление качеством/методологическое обеспечение — управление разработкой методологических рекомендаций и материалов, внесение изменений и дополнений в методологические материалы, согласование и оценка результатов работ;

• управление ресурсами — управление финансами (бюджетом), управление поставщиками и подрядными организациями, управление расчетами.

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

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

Техническая архитектура

Направление работ, связанное с построением технической архитектуры (ТА), может существенно различаться при реализации проектов создания КИС в разных компаниях. Статус наличия и готовности средств ТА, техническая политика, наличие технического персонала и т. п. могут повлиять на состав и сложность работ данного направления. Для проектов ТРК это, в первую очередь, связано с внедрением единых технологических стандартов, требующих наличия ресурсов для построения и поддержки средств ТА на местах. Тем не менее, направление создания ТА для КИС в ТРК имеет ряд характеристик, которые носят общий характер.

Во-первых, направление ТА должно включать в себя ряд обязательных независимых работ, направленных на создание отдельных компонентов ТА КИС. К ним относятся:

• построение центров обработки данных (ЦОД);
• создание транзитных узлов (ТУ);
• формирование инфраструктуры, обеспечивающей необходимый уровень информационной безопасности — корпоративной системы информационной безопасности (КСИБ);
• построение сетей передачи данных, включая корпоративную сеть передачи данных (КСПД), сети передачи данных региональных филиалов (СПД), локальные сети (ЛС) передачи данных подразделений;
• обеспечение автоматизированных рабочих мест(АРМ) пользователей КИС;
• построение резервных центров обработки данных (РЦОД).

На работы по созданию средств ТА в ТРК влияют и планы использования ТА для иных целей, кроме как под требования КИС. Например, в телекоммуникационном секторе ЦОД, скорее всего, будет использован и для реализации задач автоматизации расчетов (АСР — Billing). На "местах" реализуются задачи построения сетей передачи данных, транзитных узлов, создания рабочих мест.

Типичной ошибкой реализации задач построения объектов ТА является приоритезация задач в зависимости от объема бюджета. На практике пришлось сталкиваться со случаями, когда результаты высокобюджетных проектов создания ЦОД и КСПД оказывались невостребованными из-за того, что не нашлось времени проследить за "копеечным" проектом подключения пользователей КИС к локальной сети.

Особое внимание при реализации проектов в ТРК следует уделять информационной безопасности. Лучше изначально максимально расширить перечень задач, решение которых обеспечит безопасность данных, чем потом в ходе проекта узнать, что применение КИС может нанести ущерб бизнесу ' и сделает невозможным использование результатов проекта.

Ну и конечно следует помнить, что ТА требует квалифицированной поддержки. В том числе, поддержка средств ТА потребуется в ходе проекта внедрения программных средств, так как в большинстве случаев внедрение требует модификации и дополнительной настройки средств ТА, которые должны быть осуществлены качественно и своевременно.

Разработка и внедрение прикладных программ

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

Стратегия разработки и внедрения КИС в ТРК основана на множестве факторов и решений, но для распределенных КИС наиболее характерными и важными являются решения следующих вопросов:

• выделение "централизованных" работ, выполняемых один раз для всей структуры ТРК;
• последовательное внедрение функциональности КИС;
• организация перехода к эксплуатации.

Централизация работ

Необходимость выделения централизованной части работ при внедрении КИС в ТРК очевидна. Так легче управлять, единые для всех решения разрабатываются один раз, ресурсы концентрируются в одном месте — все это должно приводить к сокращению сроков и затрат на реализацию проекта.

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

Очевидно, что разработка приложения должна выполняться централизованно — можно сказать, что альтернатив в этом вопрос нет. Однако при этом ключевым риском является риск, что при централизованной разработке не будут учтены все требования структурных подразделений на местах. Для снижения этого риска требуется проводить углубленный анализ требований регионов, дополнительные этапы тестирования, причем начиная с самых ранних этапов проекта, с обязательным привлечением специалистов с мест.

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

Одним из эффективных решений вопроса организации разработки и внедрения КИС в ТРК является организация центров компетенции, о которых речь пойдет ниже. При этом имеет смысл говорить о создании таких центров в самом начале проекта. Спектр задач центров компетенции может начинаться с области поддержки и развития корпоративных бизнес-процессов и заканчиваться вопросами подготовки пользователей в ходе ротации персонала.

Последовательное внедрение функционала

При внедрении КИС в ТРК вопрос определения объема и последовательности внедряемого функционала приобретает принципиальный характер. С этой точки зрения важно понимать, какая функциональность КИС позволит повысить эффективность бизнес-процессов, а какая будет направлена на достижение общих целей, таких как повышение стоимости компании, точности анализа и прогнозов, выход на IPO и т. д. В первом случае внедрение функциональности будет носить инвестиционный характер с применением оценок возврата инвестиций (ROI — return of investments) — если внедрение определенной функциональности имеет конкретные оценки эффективности, то предпочтительно начинать с такой функциональности. Это может быть функциональность управления активами. В розничной торговле это может быть мерчан-дайзинг. Для многих ТРК быструю отдачу может дать управление ресурсами, как наибольшая затратная составляющая.

Но в большинстве случаев внедрение определенной функциональности КИС создает базу для стратегического развития бизнеса, и возврат инвестиций не будет носить прямой связи с этой функциональностью. В этом случае следует обратить внимание, в том числе, на вопрос удовлетворенности конечных пользователей — именно они будут реализовывать новые возможности, и успех реализации новых возможностей будет связан с использованием ИТ.

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

При последовательном внедрении функциональности КИС необходимо отдавать отчет, что какойто период — от 3 месяцев до года — будет необходимо использовать две системы: "новую" с внедренным функционалом и "старую", функционал которой предстоит заменить позднее. Чтобы не "завязнуть" в вопросах интерфейсов и взаимодействия "старой" и "новой" системы, следует выбирать функциональность и бизнес-процессы, которые максимально автономны.

Организация перехода к эксплуатации

Переход к эксплуатации может быть осуществлен как минимум по четырем сценариям. У каждого есть свои преимущества и недостатки. И важно понять, в каком случае, какой сценарий является наиболее предпочтительным.

Возможны следующие сценарии:

• "Большой взрыв";
• "Агрессивный";
• "Сверху — вниз";
• "Пилотный".

При реализации подхода "Большой взрыв" в определенный момент времени все пользователи КИС должны перейти к использованию новой функциональности. За видимыми преимуществами такого подхода — минимальные сроки перехода — стоит высокий риск неудачи в отдельных объектах структуры, вызванный потерей управляемости, что может привести к неуспеху перехода в целом.

"Большой взрыв" требует качественной разработки структуры поддержки перехода. Как известно, максимальная нагрузка на поддерживающие КИС структуры приходится именно в момент перехода к эксплуатации. Для многих ТРК будет просто невозможно единовременно привлечь столько ресурсов для обеспечения этого процесса. Дополнительные слож- ности создаст "большой взрыв" в многоуровневой структуре с тремя и более уровнями.

Снизить риск и нагрузку на ресурсы при "большом взрыве" позволяет "агрессивный подход". При таком подходе выделяют части организационной вертикали, регионы или отраслевые дивизионы, и осуществляют переход последовательно в каждой из них. Например, такой подход был применен при развертывании КИС на базе Oracle e-Business Suite в региональных компаниях связи холдинга "Связьинвест", где переход осуществлялся в две-три "волны", охватывающих от 3 до 6 региональных филиалов каждой из компаний.

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

Наиболее знакомым и низкорискованным сценарием перехода к эксплуатации является переход с использованием "пилота": по ряду критериев в компании выделяется объект или группа объектов из структуры ТРК, в которых осуществляется полный цикл внедрения, включая переход к эксплуатации и оценки результатов внедрения. При достижении успешных результатов и после адаптации этих результатов внедренные решения и модели переносят на другие структурные подразделения. Привлекательности такого подхода противостоит длительность, которая для большинства российских ТРК невозможна. Например, даже при оптимальном ходе проекта внедрения КИС в холдинге "Связьинвест", когда "пилотом" выступила бы одна из межрегиональных компаний, внедрение заняло бы от 5 до 7 лет против запланированных трех при "агрессивном подходе".

Центры компетенции

Создание центров компетенции в ТРК позволяет решить достаточно широкий круг вопросов, связанный с внедрением и последующей поддержкой внедряемой КИС. Одним из принципиальных вопросов в ходе реализации проектов КИС в ТРК является вопрос приемки результатов проектных работ. Особую актуальность этому вопросу придает комплексность и этап-ность проектных работ. Например, приемка результатов централизованных работ по проекту подразумевает, в первую очередь, обеспечение последующих децентрализованных работ. Аналогично приемка на местах должна осуществляться, в том числе, с точки зрения обеспечения целостности КИС, т. е. по единым правилам и нормам, структурами, которые смогут оперативно решить вопросы с "центром".

Следующий вопрос — оказание поддержки пользователей и реализация локальных требований.

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

При реализации проектов внедрения КИС в ТРК особое место занимает вопрос подготовки конечных пользователей. Обучение может быть построено как в очной форме, так и с применением современных средств дистанционного обучения. Основной объем материалов обучения должен разрабатываться централизованно, что позволит обеспечить высокое качество учебных материалов, а также сократить расходы за счет объема выполняемых работ. При выборе очной формы обучения осуществляется подготовка тренеров из числа ключевых пользователей или специально обученных сотрудников подразделений службы управления персоналом. В случае дистанционного обучения пользователей необходима подготовка инструкторов, готовых выполнять функции администраторов систем обучения. В каждом из вариантов обучения особое значение должно быть уделено вопросам контроля его качества. Централизованно обрабатываемые результаты обучения могут быть использованы службами персонала при мотивации сотрудников.

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

Таким образом, центр компетенции объединяет в рамках единых правил и процедур специалистов, обеспечивающих как методологическое, так и техническое обеспечение процесса внедрения, поддержки и развития КИС. Руководство ТРК при этом получит единую точку ответственности за достижение целей проекта внедрения, использования и развития КИС.

Предыдущая новость:
Управление рисками при внедрении КИС Следующая новость:
Будни и перспективы информационной безопасности