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

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

«Руна» начинала свою деятельность как региональный информационный центр компании «Консультант Плюс» и сейчас, по словам председателя ее совета директоров Михаила Орлова, основной актив группы — это договоры с клиентами. На сегодняшний день их почти 7 тыс. (в основном бухгалтеры и юристы). Основная деятельность, связанная с оказанием услуг клиентам — пользователям справочно-правовых систем «Консультант Плюс» (в том числе организацией консультаций и семинаров для них), сосредоточена в подразделении «Правовая информация». Подразделение «Линия консультаций» оказывает поддержку бухгалтерам при работе с продуктами «1С» (горячая линия и обновление типовых конфигураций). В составе компании имеется также подразделение «Издательский дом», который выпускает еженедельное деловое издание «карманного» формата «Время Бухгалтера», и подразделение «Технологии продаж», проводящее тренинги по продажам и управлению в крупных сбытовых сетях России.

Управление, адекватное бизнесу

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

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

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

Путями Нортона и Каплана

С каждым процессом тесно связан набор ключевых показателей эффективности (Key Performance Indicators, KPI), характеризующих ход его исполнения, которые также могут быть декомпозированы. Они определяют состояние бизнес-объектов, изменяемых в ходе процесса. Среди показателей верхнего уровня используются преимущественно финансовые величины. На лежащих ниже уровнях управления их постепенно вытесняют нефинансовые показатели (этого требует идеология сбалансированной системы показателей).

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

Дешево, но эффективно

«Оценивая совокупную стоимость владения, необходимо учитывать характер использования программного обеспечения» — Михаил Орлов, председатель совета директоров консалтинговой группы «Руна»«Руна» работает более 15 лет, при этом идеология процессного подхода используется здесь более десяти лет. Уже восемь лет существует примитивная автоматизация процессного подхода на основе общих папок Microsoft Exchange. «С точки зрения соотношения цены и качества это великолепный вариант», — считает Орлов. Функции примитивных процессов без распараллеливания и сложных выборов были отображены на систему папок Exchange и прав доступа к ним. В папку, соответствующую первому шагу процесса, выкладывается записка с заданием, исполнителю направляется сообщение электронной почты с уведомлением. Затем исполнитель вручную переносит записку в следующую папку бизнес-процесса и так далее до последней в процессе папки. Папки шагов вложены в родительские папки бизнес-процессов, а те в свою очередь — в папки групп бизнес-процессов на уровне отделов. Полный доступ к ним имеют хозяева данных процессов, которые проектируют и создают необходимую структуру папок. Они же контролируют ход выполнения процессов, то есть перемещения записок с заданиями.

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

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

Потоки работ и документов

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

Определившись с направлением развития, «Руна» оказалась в непростой ситуации. Выяснилось, что на момент принятия решения в мире не существовало единства мнений в определении технологии управления потоками работ. Приоритет в разработке соответствующих стандартов принадлежит образованной в 1993 году ассоциации Workflow Management Coalition. Однако, по словам системного аналитика компании «Руна» Андрея Михеева, с течением времени ее активность пошла на убыль, и она потеряла темпы развития. Инициатива перешла к возникшей в августе 2000 года отраслевой группе Business Process Management Initiative (BPMI). Она подготовила к выпуску первую версию спецификации языка моделирования бизнес-процессов Business Process Modelling Language (BPML) и графическую нотацию описания потоков работ BPMN. Впоследствии нотация BPMN была передана группе Object Management Group (OMG).

В апреле 2003 года BEA Systems, IBM, Microsoft, SAP и Siebel Systems предложили спецификацию нового языка описания потоков работ, названного Web Services Business Process Execution Language (WS-BPEL). Активное продвижение BPEL отодвинуло на задний план деятельность BPMI, фактически этот язык начинает играть роль стандарта. По оценке Андрея Михеева, он имеет очень сложную структуру и организация его поддержки в приложениях является непростой задачей. Похоже, создатели BPEL не предпринимают никаких усилий, чтобы сделать его проще и доступнее для небольших разработчиков. Поддержка BPEL доступна только крупным вендорам.

В результате, когда «Руна» подошла к необходимости использования специализированной workflow-системы, обнаружилось, что на рынке нет решений, которые удовлетворяли бы ее требованиям, а имеющиеся стандарты очень сложны в реализации и быстро меняются. Пытаясь решить проблему, компания натолкнулась на интересную инициативу Ван дер Алса, который выделил относительно небольшой набор (около 20) шаблонов в описаниях бизнес-процессов, используя очень простую диаграммную технику (www.workflowpatterns.com). В соответствии с его предложением для проверки актуальности того или иного стандарта описания потоков работ необходимо выяснить, реализуемы ли в нем эти шаблоны. Это давало возможность самостоятельного объективного выбора стандарта. В конце концов специалисты «Руны» остановили свой выбор на использовании UML как более простой в реализации технике, в основном соответствовавшей критерию Ван дер Алса.

Процессы и клиенты

«Мы хотели, чтобы workflow-система превратилась в основу интеграции многочисленных приложений, используемых в компании», — отмечает Владимир Кошеляев, ИТ-руководитель компании «Руна». В частности, на момент принятия решения о внедрении системы workflow в «Руне» функционировала CRM-система, созданная собственными силами на основе платформы «1С: Предприятие 7.7». Постоянно возникала необходимость переноса данных о клиентах из нее в задания исполнителям процессов. Добиться интеграции доступными ресурсами Exchange было очень сложно.

«Мы рассматриваем CRM-систему исключительно как инструмент управления отношениями с клиентами нашего бизнеса, — поясняет Орлов. — Это клиентская база и ИТ-поддержка процессов переговоров с клиентами о приобретении услуг и обслуживании, процессов взаиморасчетов с ними, связанный с этим документооборот». Спецификация CRM-системы в «Руне» упрощается за счет того, что компания предоставляет типовые услуги. Сложность управленческих задач в компании определяется в основном сложностью организации бизнес-процессов.

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

Плюсы и минусы свободных решений

«Организация поддержки языка BPEL в приложениях является непростой задачей» — Андрей Михеев, системный аналитик компании «Руна»Когда стало ясно, что компании необходима специализированная workflow-система, был проведен тщательный анализ рынка. По результатам анализа закрытых решений был сделан вывод о том, что однозначно удобных для «Руны» решений среди них нет. Тогда компания обратилась к уже существовавшим на тот момент открытым решениям.

«Модель свободно распространяемого ПО близка «Руне», вероятно в силу того, что ее бизнес имеет консалтинговый характер, то есть идеологически близкую модель», — считает Кошеляев. В результате было решено сделать ставку на одну из свободно распространяемых workflow-систем на основе лицензии LGPL.

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

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

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

В результате выбор был сделан в пользу решения JBPM, которое развивается сообществом JBOSS, специализирующимся на разработке программного обеспечения промежуточного слоя на основе Java. Редактор бизнес-процессов также решено было взять из проекта JBPM и доработать собственными силами. Другие компоненты (систему аутентификации и авторизации, клиентское приложение и т.п.) решили разработать самостоятельно, используя открытые библиотеки (hibernate, struts и др.).

Принцип всеобщего согласия

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

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

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

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

Итоги и перспективы

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

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

В то же самое время вокруг компании формировался коллектив внештатных работников. Поскольку уровень зрелости системы позволял выделять изолированные задачи ее развития, их решение можно было возложить на внешних разработчиков. Одним из наиболее сложных вопросов при таком стиле разработки является организация управления изменениями. С этой целью «Руна» воспользовалась ресурсами, предоставляемыми сайтом www.sourceforge.net. В качестве основного инструмента здесь используется продукт Eclipse. Разработка всех общих компонент системы ведется в репозитарии портала Sourceforge.

Специфические для «Руны» компоненты хранятся в ее репозитарии. При необходимости создать очередную версию для «Руны» коды из разных репозитариев объединяются в одном проекте.

По словам Андрея Михеева, в настоящее время компания стремится создать среду разработки, которую можно финансировать лишь частично. Это реально, например, если бы некоторые организации стремились адаптировать эту систему для решения своих задач, оставляя свои версии общедоступными. Такие предложения постоянно поступают, но все они связаны с новой, третьей версией ядра JBPM, в числе возможностей которой — поддержка BPEL. К осени Орлов, Кошеляев и Михеев планируют закончить все работы по переходу на него.

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

На данный момент Орлов считает, что созданная в компании система RunaWFE находится в состоянии стабильной бета-версии, к тому же «Руна» пока не готова организовать коммерческую техподдержку продукта. Это решение доступно «as-is» (то есть без обязательств со стороны разработчика) на портале sourceforge (sourceforge.net/projects/runawfe/). Если после перехода на третью версию ядра станет ясно, что вокруг решения собирается сообщество разработчиков и пользователей, то возможны три варианта: «Руна» передаст разработку сообществу на основе лицензии GPL; разработка будет продана крупной компании-разработчику; «Руна» организует у себя новое бизнес-направление по дальнейшему развитию и техподдержке RunaWFE.