По мере взросления компании способы и формы коллективной работы в ней эволюционируют. Именно так проходило движение к процессной модели построения коммуникаций в ЗАО «Компания ТрансТелеКом» (торговая марка ТТК). Об этом, а также о проблемах, с которыми пришлось столкнуться на этом пути, мы беседуем с CIO ТТК Леонидом Ивановым.
Intelligent Enterprise: Как с вашей точки зрения надо подходить к вопросу автоматизации коммуникаций в компании?
Леонид Иванов: Вначале следует разобраться в том, какие существуют коммуникации и как они развиваются, а уж какими ИТ‑средствами их поддерживать — это вопрос второстепенный. Взаимодействие сотрудников в компании можно разбить на несколько типов. Первый — хаотичный. Любое общение можно свести к набору сообщений, а уж как они будут переданы — не так и важно. К этому типу относится устное общение, в том числе телефонные переговоры, электронная почта, сервисы мгновенных сообщений.
Первый шаг к упорядочиванию взаимодействия — введение иерархии и выстраивание сообщений по принципу «приказ — исполнение». Тогда сообщение «старшего по званию» становится уже не просто сообщением, а указанием, обязательным к исполнению. В электронном мире этому соответствуют классические системы электронного документооборота. Каждое сообщение при этом имеет статус «надо делать», но формально его статус не регламентирован. Что именно надо делать, обычно следует из содержания самого сообщения, и действия эти могут иметь очень много вариантов. Путь, по которому пойдет документ, может оказаться непредсказуемым, из‑за чего такой процесс трудно контролировать и контроль обычно ограничивается статусом «исполнен/не исполнен». Например, на моей служебной записке с просьбой выдать мобильный телефон ответственный сотрудник может написать разрешение выдать, может запросить склад о наличии таких аппаратов, может запросить финансовую службу о наличии средств на закупку и оплату переговоров, могут возникнуть и другие уточняющие запросы. И моя записка, таким образом, отправится по самому неожиданному пути, а ответа, и уж тем более телефона, я буду ждать неопределенно долго.
Следующее эволюционное состояние — процессный подход, когда всё, что происходит в компании, разложено на процессы и существуют точные регламенты, что в каком случае должно происходить. Каждый документ, обрабатываемый при процессном подходе, имеет строго определенные стадии, и цель каждого процесса в том, чтобы к финальной стадии он оказался в регламентированные сроки. В случае с телефоном сотрудник, принимающий решение, может поставить лишь конечное и притом небольшое число резолюций на моем заявлении, движение документа станет предсказуемым, а продолжительность его обработки можно будет фиксировать, поставив ограничения на время принятия решения. Любая коллективная работа эволюционирует от хаотичного общения «каждый с каждым» к процессному подходу, когда все действия описаны и маршруты заданы. Возможно, вслед за процессным подходом будет предложено нечто новое в организации коллективной работы, но пока вектор дальнейшего развития не просматривается.
Когда компания только образуется, она находится на первой стадии. Все вопросы решаются путём обычного общения. Но по мере роста бизнеса общение трансформируется, возникает потребность в регламентах. Появляются элементы классического документооборота, затем процессный подход. В результате в компаниях начиная со средних обычно присутствуют все три стадии.
Если мы эволюционируем, то у нас доля хаотичного общения должна уменьшаться, а доля других его видов — расти. Но наряду с общением как таковым есть задача анализа происходящего. Хаотичное общение мы практически не можем контролировать. Точнее, можем, но только в целом или статистически, поскольку нынешними средствами анализировать, «что там внутри», о чем люди говорят и пишут, проблематично, а главное, неясно, что в результате такого анализа можно получить полезного. Классический электронный документооборот существенно не улучшает сам процесс взаимодействия, но людям, которые пытаются его контролировать, дает для этого инструмент, поэтому контрольная функция усиливается. Когда появляется процессный подход, существенно улучшается взаимодействие в коллективе за счет резкого уменьшения непродуктивных сообщений, одновременно появляются и более изощренные методы контроля процессов.
Как развивались процессы коммуникации у вас в компании, какие эволюционные стадии вы прошли?
Сначала появилась потребность в хранении большого количества документов. Еще неважно было, каким способом оно будет реализовано, но это был первый шаг к структурированию информации. Наши менеджеры по продажам постоянно подписывали новые заказы на подключение клиентов, заказы эти накапливались, и их начинали исполнять. Отдел координации заказов — те, кто дает указание на подключение услуги, — довольно быстро заметил, что их нужно учитывать, упорядочивать, и ввел простейшие статусы заказа: «подписан», «подключается», «подключен», «отключен», «рассматривается» и тому подобное.
Это была первая попытка формализовать процессы, и работа тогда велась в Microsoft Exсel. Затем стало ясно, что если нужно один документ Microsoft Exсel использовать совместно, то возникает слишком много проблем и требуется надежное серверное решение. Мы выбрали в качестве платформы хранения документов IBM Lotus, стали анализировать простейшие статусы и переходы между ними, появилась идея «маршрутов», когда документ, имеющий определенный статус, дальше может перейти в другие строго определенные статусы, причём вариантов таких переходов немного и все они фиксированы. Для начала все статусы и переходы между ними мы жестко запрограммировали.
Однако едва это решение приобрело законченный вид ИТ‑системы и заработало, как выяснилось, что это далеко не всё. Каждый раз, подключая клиента, сотрудник отдела координации заказов пишет в техническую службу письмо с указанием даты подключения и некоторых других параметров. Естественно, пришла мысль не держать все параметры внутри письма, а при переводе заказа из одного статуса в другой генерировать сообщения автоматически, включая в них минимально необходимую информацию и гиперссылку на документ в базе данных.
Конечно, всё это было придумано ещё до нас, мы просто изучали ядро workflow в IBM Lotus и использовали наиболее привлекательные идеи. Но двигаясь таким образом, мы быстро поняли, что если специально программировать каждый новый «чих», то не хватит никаких программистов. И решили разработать собственную платформу workflow, которая позволяла бы с минимальными издержками добавлять статусы и правила перехода между ними. Конечно, при этом мы проходили путь, уже не однажды пройденный на Западе, но ясно полученный результат стоил того.
А когда такая платформа была готова, выяснилось, что в компании великое множество Exсel-таблиц, с помощью которых подразделения пытаются как‑то описывать свои процессы. Так постепенно сложился метод перехода к автоматизации процессов. В каждом подразделении мы говорили: «Так… что тут у вас, табличка? Давайте для начала перенесем ее в базу данных IBM Lotus». Заводим в базу, делаем форму доступа к документу. Из таблички получается хранилище, определяются роли пользователей системы, определяются статусы тех или иных документов и соответствующих им фаз рабочего процесса, настраивается автоматическая рассылка уведомлений по электронной почте. А дальше все развитие зависит от того, насколько сотрудники и руководители подразделений готовы принять эту работу и участвовать в ней.
Если говорить об ИТ‑средствах, то у нас сложилась следующая схема. Для поддержки классического документооборота используем тиражируемый продукт — Company Media (разработка компании «ИнтерТраст», в промышленной эксплуатации с 2001 года). Система построена по ГОСТам в области организации документооборота, но она не предназначена для автоматизации процессного подхода, так что эти задачи мы решаем в своей собственной workflow‑системе на IBM Lotus. Для хаотичного общения используем электронную почту, тоже на IBM Lotus, видеоконференцсвязь и традиционные телефоны.
Описание и регламентация процессов — не такая простая задача, особенно в области коммуникаций. Кто должен описывать процессы и думать над их оптимизацией? С какими проблемами вы сталкивались при этом?
Один подход заключается в том, что это обязанность владельца процесса. Другой — что лучше поручить это специально выделенным специалистам, которые заняты исключительно такой работой и потому знают ее намного лучше, чем любой руководитель подразделения. Но на практике происходит так. Приходят ко мне юристы и говорят, что после выхода на розничный рынок число оформляемых доверенностей стремительно растет. Теперь их на порядок больше, чем год назад, когда мы работали исключительно с корпоративными клиентами. Они имеют срок действия и должны быть своевременно переоформлены. Нужна информационная система, чтобы следить за всем этим.
Мы предложили юридическому департаменту создать систему на нашей workflow-платформе, обеспечив при этом электронное согласование заявок на выдачу доверенностей. Поскольку заявка будет содержать в себе информацию о доверенном лице, не составит никакой проблемы реализовать генератор текста доверенности для дальнейшей печати бумажного документа. По готовности доверенности система отправит сотруднику уведомление о том, что ему следует зайти в юридический отдел и подписать документ. О необходимости переоформления в конце срока действия система сообщит автоматически.
По сути дела коллективная работа — это конвейер. Каждый сотрудник выполняет элементарную операцию, а на выходе мы имеем результат. Ведь на конвейере не просят наладчика описать, что он делает, выстроить оптимальную последовательность операций. Наоборот, каждый получает технологическую карту, которой и следует. Разрабатывают карты технологи. По моему глубокому убеждению в коллективной работе должно быть так же: нужны выделенные технологи, которые знают процессы лучше других, умеют их описывать и представляют себе, как их можно оптимизировать. Это могут быть либо люди, знающие все процессы по собственному опыту, либо те, кого специально обучали раскладывать процессы на элементы. Сами участники процессов могут при этом быть экспертами, консультантами, то есть обеспечивать обратную связь с технологами по функционированию процесса. Кроме всего прочего описание — дело затратное, в том числе по времени. Руководителю подразделения, занятому повседневной операционной деятельностью, сложно найти время для разработки документов, регламентирующих процессы в зоне его ответственности.
При описании важен следующий аспект: нужно двигаться сверху вниз от крупных блоков, с основных операций, а не начинать с элементарных действий. Очень часто народ сбивается на попытки описать всё до последней детали. Это ошибка! Прежде всего надо выделить несколько ключевых стадий и опираясь на них построить ИТ‑систему, которая поддержит эти основные операции. Когда она заработает, станет нормальным рабочим инструментом, вы поймёте, что не все состояния описали, не все статусы включили и необходимо добавить еще. ИТ‑специалисты это быстро сделают в любой момент на workflow-платформе, а до тех пор всё упущенное поживет в «хаотичном» общении. Но вначале основные функции должны зажить, заработать. Только когда будут налажены основные стадии, станет ясно, чего действительно не хватает.
Я не раз был свидетелем споров о том, сколько необходимо стадий, но только практика может показать, какие из них и правда стоит включить. Вначале таких стадий бывает, скажем, пять, а через два-три года работы по процессному подходу — уже более тридцати. Это результат нашего эволюционного развития. Иначе сложится нелепая ситуация: не поняв, что сборку автомобиля начинают с кузова, к которому потом крепится двигатель, а потом ходовая часть, решать вопрос, в каком порядке болты на колесах затягивать, нет смысла. Нужно придерживаться принципа «от общего к частному».
К коллективной работе часто относят использование корпоративных баз знаний, поисковых сервисов, блогов и других интерактивных средств взаимодействия. Насколько все это нужно для работы вашей компании?
База знаний в любой организации начинает формироваться с самого рождения. Если фирма находится на стадии хаотичного общения, то и на этом этапе такая база есть — распределенная и не электронная, а в головах сотрудников. При процессном подходе она принимает вид электронных баз данных, где фиксируется, кто, когда и что сделал, какое решение принял, и иногда из них можно извлекать совершенно неожиданную информацию. Однажды у нас была совершена серьезная ошибка, начали искать виновного. Им оказался один из координаторов, не выдавший вовремя необходимое указание. Просмотрев по лог-файлам загрузку и активность каждого сотрудника этого подразделения, мы увидели, что совершил ошибку самый загруженный из них, тот, кто работал в системе больше всех остальных, и соответственно вероятность ошибки у него была повышенная. Подобный анализ по идее и должна была бы провести база знаний. Однако систем, способных делать это автоматически, без участия ИТ‑специалиста, пока нет.
Что касается форумов и блогов, то продолжая аналогию с конвейером, мы получим такую картину: вместо того чтобы работать, слесари сидят в сторонке и обсуждают, кто как гайки завинчивает. Один говорит: я гаечный ключ тремя пальцами держу. А другой — а я всей пятерней… Вот это и есть корпоративные форумы-блоги. Их цель — взаимное информирование и обмен опытом, и если серьезно, то они вполне пригодны для мозговых штурмов, которые очень полезны, когда мы обсуждаем, куда идти и что делать. Но это функция развития, а не текущей деятельности. Когда решение уже принято, технолог описал процесс, конвейер настроен и заработал, сфера применения форумов резко сужается до приема от участников конвейера сообщений о возникающих на нем недоразумениях и предложений по улучшению процесса.
В принципе форумы и блоги — это неплохо, и, возможно, какие‑то проблемы, в том числе в ИТ‑департаменте, можно было бы с их помощью решать коллективно. Но тогда все сотрудники должны постоянно эти форумы и блоги читать, писать новые сообщения, но ведь мы‑то пришли сюда работать.
На мой взгляд, для эффективного использования форумов, блогов и других интерактивных инструментов общения нужен поиск, но не просто полнотекстовый, а семантический, способный «понимать» смысл написанного и автоматически отделять зерна смысла, значимой информации, от шелухи, К сожалению, таких инструментов пока нет, а без них поиск информации в форумах и блогах отнимает непозволительно много времени.
