Поделиться
СЭД берет курс на кейс-менеджмент
Отрасль СЭД развивается эволюционно уже около 20 лет. За это время базовая функциональность отточена до идеального состояния. Перенос этих решений на новые платформы и даже в "облака" в принципе ничего не меняет. Но сегодня руководители ходят с iPad'ами и требуют убрать с их стола все бумаги, заказчики хотят сквозной автоматизации даже неформализованных бизнес-процессов. Решить эту задачу поможет новая концепция ЭДО – кейс-менеджмент. СЭД предыдущего поколения хорошо обслуживают лишь управленческие процессы верхнего уровня, пока задание спускается от руководителя до исполнителя по иерархической лестнице. Какая-либо инициатива, горизонтальные связи и коллективная работа по проблеме в такой модели управления не рассматривается. Это отнюдь не означает, что исполнители из разных подразделений не общаются между собой. Просто руководство это не интересует, и поэтому система не видит никаких горизонтальных бизнес-процессов.До сих пор такая ситуация в принципе всех устраивала: документооборот был преимущественно бумажным, а СЭД использовались для регистрации движения документов и контроля исполнительской дисциплины.
Минусы старой парадигмы
Так чем плоха прежняя парадигма? Классические СЭД наследуют методы работы из доэлектронной эры. Бумаги приходят в организацию, складываются в стопки, подшиваются в дела. Человеку порой приходится пересмотреть множество папок, прежде чем будет найдена нужная для ответа на поступивший запрос информация. И контроль устроен по хронологическому принципу. Именно поэтому самыми священными реквизитами для делопроизводителей являются регистрационный номер и дата документа, но они лишь фиксируют его положение на оси времени.
Поскольку никаких других традиций управления, кроме партийно-советской бюрократии в России не было, бизнес заимствовал эти методы
Такой взгляд вынуждает нас полностью абстрагироваться от содержательной, смысловой части работы — с какой целью поступил к нам данный документ, какие процессы он инициирует и какой результат ожидается на выходе.
Поскольку никаких других традиций управления, кроме партийно-советской бюрократии в России не было, бизнес заимствовал эти методы. И поэтому СЭД, созданные по модели обкомов КПСС, использовались повсеместно, как в госуправлении, так и в бизнесе.
Однако в современных условиях эта жестко централизованная модель перестала быть эффективной. Руководитель (на любом уровне, не только на самом верхнем), сколь бы он ни был гениальным, не в состоянии лично управлять всем и держать в своей голове все взаимосвязи между документами и делами.
Начались поиски более эффективной модели управления.
BPM: стремление к эффективности
Может показаться, что все эти задачи может решить концепция BPM, то есть увязать все активности с бизнес-процессами и стратегическими целями организации. Нужно только смоделировать наши процессы, определить владельцев, назначить исполнителей — и вперед! Действительно, вслед за тем, как были автоматизированы базовые функции делопроизводства, все разработчики СЭД оснастили свои системы модулями workflow, которые доросли постепенно и до BPM.
Но и BPM не решает всех задач, возникающих при взаимодействии людей в ходе работы. Данный тип систем хорошо работает там, где есть формальные, устоявшиеся бизнес-процессы и довольно мало исключительных ситуаций. Чего совершенно нельзя сказать о любой профессиональной деятельности, связанной с принятием решений. Если посмотреть на работу юриста, следователя, врача, банковского работника, госслужащего, иначе говоря, любого специалиста, можно заметить, что при всей ее повторяемости, каждый случай уникален и сроки всегда разные. BPM здесь явно не применим.
Как управлять неформализованными процессами?
Тут на сцену выходит другая концепция — кейс-менеджмент. В широком смысле кейс-менеджмент – это управление неструктурированными или частично структурированными бизнес-процессами, инициированными клиентами. Здесь под клиентом может пониматься как собственно клиент, обратившийся в компанию, так и гражданин, получающий госуслугу, или сотрудник организации, которому нужен какой-то внутренний сервис.
Например, посмотрим на такие типичные ситуации как открытие счета (или иного аккаунта), обращение за кредитом, оформление страховки и страховых случаев, управление инвестициями и пенсионными счетами и пр.
Все это кейсы. У данных бизнес-процессов всегда есть заинтересованное лицо — получатель услуги или информации, который инициирует всю работу.
Если обобщить приведенные примеры, то видно, что во всех случаях можно выделить элемент работы, связанный с какой-то бизнес-транзакцией, который обязательно включает выполнение некоторых процедур. Ключевая особенность данного подхода – нацеленность на результат, на удовлетворение запроса.
Однако пути его достижения часто не прописаны детально. Подход кейс-менеджмент фокусируется на том, что должно быть сделано, но не всегда определяет, как именно.
Поэтому, в отличие от традиционного подхода BPM, использование кейс-менеджмента дает сотрудникам большую гибкость и свободу действий. Реальная жизнь сложнее, чем схемы бизнес-процессов, нарисованные аналитиками. Все детали учесть невозможно. Методология кейс-менеджмента позволяет, опираясь на типовой шаблон, "на лету" выстраивать бизнес-процессы и включать дополнительные документы и участников в зависимости от конкретной ситуации.
Что отличает кейс от проекта?
На первый взгляд может показаться, что работу, выполняемую как кейс, можно описать в метафоре проекта. Особенно если взять достаточно сложные кейсы с множеством участников и процедур. И наоборот, может возникнуть соблазн использовать Case Management вместо Project Management, поскольку кейсы выглядят проще, чем проекты.
Чтобы избежать путаницы, предлагается руководствоваться следующими критериями. Во-первых, кейс не должен быть слишком сложным. Это обычная работа, выполняемая специалистами линейных бизнес-подразделений компании. (т.е. не требуется выделенный руководитель проекта.)
Затем, кейс должен быть повторяемым. Поскольку существуют затраты на конфигурацию и настройку шаблона кейса, они будут обоснованы только в случае выигрыша в производительности за счет многократного использования шаблона. Программировать уникальную ситуацию не имеет смысла.
Короткая ссылка
