Управление бизнес-процессами с помощью информационных систем актуально практически для любой организации. Исходные данные для него обычно поставляют транзакционные системы, однако в последнее время наряду с ними начинает играть важную роль неструктурированный и слабоструктурированный корпоративный контент. Автоматизация бизнес-процессов целиком или значимых их фрагментов все чаще оказывается в центре внимания, замещая собой проекты внедрения отдельных приложений.
Олег Бейлезон, архитектор решений, «Логика бизнеса»
Владимир Панов, главный архитектор, Intertrust
Александр Балакирев, заместитель генерального директора по ИТ, Государственная Третьяковская галерея
Лидия Семичастная, начальник управления ИТ, «Восток-Сервис»
Александр Краснов, заместитель генерального директора по ИТ, группа компаний «Разгуляй»
Николай Гегамов, ИТ-директор, торговая сеть Rendez-Vous
Intelligent Enterprise: Давайте начнем с практического опыта. Какие задачи автоматизации производственных цепочек, целостных процессов, связанных с документами, доводилось вам решать?
Александр Краснов: Десять лет назад я был ИТ-директором компании «Крок», где мы сами разрабатывали механизмы поддержки сквозных бизнес-процессов. Один из таких механизмов — «Старт проекта»: в нем участвовало множество подразделений, проходила масса согласований, готовились разнообразные документы, а затем, когда проект был всеми согласован и представлена вся необходимая информация, этот факт отражался во множестве информационных систем.
Доводилось внедрять СЭД не в виде типичного решения для организационно-распорядительных документов [ОРД], а для автоматизации ключевого бизнес-процесса целиком — от оформления заявки до отгрузки потребителю. Это была компания-дистрибьютор, и тоже требовалось связывать несколько ИТ-систем. Поверх них всех действовало единое приложение, куда вводились данные.
В «Разгуляе» мы только приступили к комплексной автоматизации процессов. Пока мы внедряем СЭД для поддержки ОРД и выявляем, структурируем те бизнес-процессы, которые в дальнейшем будем полностью автоматизировать. Уже понятно, что в первую очередь это будут финансовые процессы: заявки на закупку, на оплату должны быть связаны с тендерами. Это большой пласт работы года на полтора-два. Задача очень общая, с нею сталкиваются все крупные компании.
Лидия Семичастная: У нас распределенный холдинг, склады, магазины, более восьмидесяти филиалов по всей стране. Стояла задача создать единое информационное пространство. В качестве основной выбрали платформу «1С», и интеграция была такой: собственная самописная система, часть модулей SAP и «1С». Внедренцы SAP с самого начала говорили мне, что так нельзя, что нужно все снести и поставить одну SAP. Но мы пошли на медленную ползучую интеграцию, которая зато «прилипает намертво». Мы идем по процессу постепенно. Скажем, сбыт с логистикой, с полной интеграцией всех наших приложений: мы объединили всё для поддержки логистики, и так и живем вот уже три года. Деньги, вложенные в SAP, явно уже окупились, хотя точных расчетов мы не делаем.
Документооборот мы пока не внедряем. С точки зрения инфраструктуры нет никаких проблем, но бизнес не видит необходимости все документы хранить в электронном виде. Однако у нас автоматизированы специфические производственные цепочки, связанные с обработкой контента. Наше производство — швейные фабрики, процессы у них очень трудоемкие, плохо согласуемые, особенно система спецзаказов, где требуется множество повторных согласований. Два года назад мы полностью автоматизировали процесс. Клиент, сбытовик, конструктор, закупщик ткани, менеджер, который работает с фабрикой, — все связаны в одну цепочку. Мы сделали это в нашей старой самописной системе. Это сложный алгоритм, в нем возможны петли, возвраты назад, и бизнес хочет его развивать.
Пару раз пробовала предложить бизнесу документооборот, но смысла в этом нет: надо делать то, что дает отдачу, другое не заработает. Когда управленцы, производственники сами говорят: «Мы без этого не можем», — вот тогда и надо делать. Тогда они живут в этих схемах, мыслят их объектами.
Александр Балакирев: У нас несколько бизнес-цепочек, которые существуют параллельно. Финансово-хозяйственную деятельность поддерживают несколько глубоко интегрированных систем. Отдельно стоит упомянуть билетную систему с экскурсионным модулем, которая глубоко интегрирована с бухгалтерией и системой планирования. Есть проблемы с поддержкой такой непростой интеграции, так как мы живем по 94-ФЗ, а это иногда создаёт определённые сложности с выбором фирмы-исполнителя.
Другой блок процессов касается учёта музейных предметов и коллекций. Бизнес-процессы у каждого музея уникальные, в том числе и у нас. Уже существующие программные продукты приходится дорабатывать под нужды каждого конкретного музея, что тоже процесс не тривиальный, поскольку сотрудники отделов учёта и хранения предпочитают мыслить своими категориями, их трудно заставить работать иначе, чем так, как они привыкли за долгие годы.
У нас есть также отрицательный опыт разработки и внедрения системы автоматизации планирования. Это был полноценный документооборот, но потом сменилась команда, а обеспечить преемственность не получилось, так как система не являлась промышленной.
Я хочу приучить людей работать с электронным документооборотом. Пока мы на первой стадии: «Не хочу и не буду». Но постепенно методом «ползучей революции» мы добьемся своего.
Николай Гегамов: Удобно и эффективно отдельные процессы, связанные с документами, постепенно автоматизировать в ERP-системе или в других уже находящихся в эксплуатации приложениях — с едиными справочниками, знакомым интерфейсом. Тогда и пользователи не воспринимают изменения в штыки, поскольку они видят, что с каждым новым шагом, с каждым набором изменений им становится удобней работать. Мы так и сделали, создав блок документооборота непосредственно в ERP-системе. Начинали с автоматизации сбора заявок на все закупаемые товары и на модификацию ПО, в дальнейшем легко обобщили шаблоны на все виды обращений. Бизнес-процессы прохождения заявок гибки и настраиваемы, а все формализованные значения выбираются из знакомых справочников (сотрудники, подразделения, работы, товары и т. д.).
Александр Краснов: Есть производства, есть их специфическая деятельность, а есть централизованные процессы всего холдинга. Они не могут лежать в отдельных частных системах, они централизованы и поэтому должны быть выше этих систем и интегрироваться с ними. На производстве стоят ERP или что-то еще, где собираются данные, ведется бюджетирование, а эти верхние системы забирают из них информацию и потом возвращают необходимое. Таким образом пользователи работают не с кучей информационных систем, а с какой-то одной. Это зрелая и отлаженная архитектура в холдинговых структурах.
Николай Гегамов: В начале разговора я упомянул о неоспоримых плюсах интегрированной в ERP (КИС) системы документооборота. К сожалению, как, наверное, у любого решения, у этого также есть и свои минусы, которые проявляются при определенных обстоятельствах. Во-первых, это дополнительный функционал, который утяжеляет программу. Во-вторых, скорее всего это и дополнительные пользователи в системе, которых могло бы и не быть. Здесь вопрос количества лицензий, а иногда и быстродействия. И наконец в-третьих — проблема распределенности базы данных. Одной из характеристик рассматриваемых систем является большое количество неструктурированного контента — от скан-образов документов до видео. Обычно КИС находится в ЦОДе. Традиционно основными пользователями системы документооборота являются обитатели центрального офиса. Таким образом, из-за того что эта система вмонтирована в КИС, по сети параллельно с оперативным контуром вынужденно передаются не только простые запросы документооборота, но и все эти медиафайлы: при привязке, просмотре и печати. Это очень засоряет трафик. Если бы приложение было выделенным, его можно было бы держать в центральном офисе либо в другом ЦОДе и трафики не накладывались бы друг на друга.
Владимир Панов: Наша система CompanyMedia — корпоративная платформа поддержки принятия решений, управления временем, задачами и личной результативностью — сейчас проходит серьезную переработку. Когда-то она была построена на IBM Lotus Domino и постепенно обрастала задачами заказчиков. Интеграции с ERP у нас было очень мало. Интеграционные проекты — это относительно редкие случаи, у каждого третьего-десятого клиента. Бывает так, что сначала внедряется только модуль для обработки организационно-распорядительных документов, а потом клиенты уже сами дорабатывают какие-то функции. Зачастую мы и сами потом удивляемся, что построили клиенты на нашей платформе. Это обнаруживается при апгрейде на новые версии, спустя несколько лет жизни приложения.
Олег Бейлезон: Еще десять лет назад в первой «Логике бизнеса» мы выполняли проект, связанный с выдачей банком розничных кредитов, в котором задачи передавались от сотрудника сотруднику по разветвленной системе правил. Была интеграция с CRM, и все заканчивалось выдачей пластиковой карты.
Я вижу большое недоверие к покупным системам. Почему? Потому что все боятся: вот сейчас купим, не разберемся, всё снесем, и будет плохо. Надежней самим писать и поддерживать код. В проекте, о котором я говорю, банк полностью перехватил у нас инициативу в развитии продукта, продолжал развивать систему собственными силами.
Были примеры и в телекоме. Вот, скажем, мультисервисная компания, приходят заявки на подключение новых услуг. Это целая история: есть техническая возможность или нет, имеются ли на это деньги у самой компании, есть ли они у клиента. Технический и коммерческий отделы — самые заклятые друзья. Основная особенность в том, что надо разобраться с процессами, надо как минимум их описать, а потом эту модель согласовать со всеми участниками.
Примечательно, что в предыдущих случаях все системы, которые мы связывали, содержали четко структурированную информацию, но уже в этом телекоммуникационном проекте появились картинки: изображения топологии сети, эскизы соединений «как все будет выглядеть», схемы, графические образы. Их тоже нужно было сделать доступными для обсуждения. Это был 2006 год.
Потом пошел вал таких запросов, когда для исполнения процесса необходимо подтягивать неструктурированные данные. Причем за это время произошли значительные изменения в BPM-системах. Раньше, в Ultimus, например, для интеграции просто было «оставлено место», открыты API — и всё. В современных приложениях, таких как WebMethods, есть инструменты сращивания с другими пакетами, по сути это интеграционная шина.
Совсем недавно на базе WebMethods мы делали проект по сбору кредитов. В нем BPM — это та интеграционная ось, вокруг которой и собирались все остальные приложения. Процесс сбора долгов сопровождается огромным количеством документов, в основном бумажных. Их нужно либо готовить, либо отсканировать и приложить, причем наличие или отсутствие определенного документа в данный момент определяет дальнейший ход процесса.
Часть бизнес-процессов просто сводится к тому, чтобы определенный документ положить в нужное место. Поэтому в BPM нам пришлось организовать управление неструктурированным контентом. В том числе его структурировать, генерировать его и связанные с ним события. В этом банке для документооборота использовался Lotus Notes, вернее их собственная разработка на его базе. Они сами проанализировали эту разработку, решили, что она их не устраивает, и просили нас все это сделать в BPM, поскольку получались слишком сложные цепочки, слишком много интеграции.
После окончания BPM-проекта в банке задумались об архиве: ведь документы постоянно накапливаются, но лежат просто кучей. При таком подходе получить доступ к ним можно только через процессы, которые скорее всего уже закончились. Архив и управление процессами — принципиально разные задачи, которые в одной системе до недавних пор решались плохо.
Intelligent Enterprise: С какими типами неструктурированного контента вы сталкиваетесь?
Александр Балакирев: Кроме внедрения учётной музейной системы перед нами стоит еще задача хранения цифрового музейного контента. При создании системы хранения мы столкнулись со множеством проблем. Цифровой музейный контент, который был накоплен за долгие годы, представляет собой крайне неоднородный массив данных. В итоге возникла проблема выверки содержимого электронных архивов. А так как архивы эти создавались на оборудовании, доступном на тот момент, качество этого контента, как правило, не соответствует современным требованиям.
Что касается современной оцифровки, то это технологически и организационно сложный процесс, в котором задействованы различные отделы музея. Работы по оцифровке у нас проводятся в двух специально оборудованных студиях. При оцифровке музейного предмета может получаться несколько изображений, примерно по 70—80 Мбайт каждое. Это предъявляет определённые требования как к системе хранения и обработки информации, так и к инфраструктуре в целом.
В будущем нас ждёт оцифровка колоссального архива фотоматериалов, до которого у нас пока не доходят руки. Это фотопластины, слайды, фотографии начала века, есть большой видеоархив, который тоже ждёт своего часа. И это далеко не полный перечень того, что нам ещё предстоит оцифровать.
Николай Гегамов: Наш неструктурированный контент прежде всего порождает самое банальное сканирование документов. Далее — контент, связанный с товаром. У нас это обувь. Это оцифрованные каталоги (помимо глянцевых), которые мы выпускаем для каждой коллекции.
Фотографии для ERP-системы и интернет-магазина. Еще до поступления конкретной модели в продажу мы размещаем фото в справочнике товара в КИС. Позже для размещения на сайте интернет-магазина снимаем каждую модель на специальном стенде с разных позиций в гораздо более высоком качестве. Допускаю, что немного погодя для сайта будем снимать и видео с демонстрацией продукта. Например, дама демонстрирует молнию, подкладку, измеряет высоту каблука, примеряет обувь, выбирает подходящую сумочку… Это однозначно нужно бизнесу, тут только вопрос времени. Думаю, что дойдем и до виртуальных примерочных.
Лидия Семичастная: Наш конструкторский отдел порождает огромные массивы документации. Мы пытались внедрить PDM-систему, но после двух лет работы пришлось от нее отказаться, так как изначально бизнес поставил неадекватную задачу. Пока ИТ-служба никак не обрабатывает конструкторскую документацию. Задача связать разработку и фабрики осталась и пока не решена.
Второй блок контента — это маркетологи. Их очень трудно включить в общую систему, а контента они создают много. Все данные о товаре мы храним в SAP. Но маркетинг ведет собственный архив фотографий, имеет свои коды товаров по каталогам, которые они запускают в печать ежегодно. Каталог только опосредованно связан с базой данных SAP. Они как-то пытаются в ручном режиме установить соответствие, и идет настоящая война, с моей стороны — жесткий прессинг и требование, чтобы они всё внесли в ERP, чтобы все филиалы получали актуальную и достоверную информацию о товарах.
С июня я занимаюсь новым проектом по неструктурированному контенту. Мы вышли на рынок бизнес-аутсорсинга, полностью берем на себя обеспечение промышленных предприятий средствами защиты и спецодеждой. Есть очень много регламентирующих документов о том, сколько, где и каких средств защиты, видов одежды и обуви требуется, каков их расход. Наш проект для «Северстали» — обслуживание 35 тыс. человек, разнообразнейшие условия труда, вредные, опасные производства, различные климатические условия. Просто собрать воедино все регламенты и ограничения, научиться автоматически их обрабатывать — сложная задача.
Мы готовим онлайн-калькулятор с учетом некоторых из этих регламентов, чтобы представители разных производств или сферы услуг могли быстро прикинуть, что им даст наш аутсорсинг: сколько и какой одежды, средств защиты им понадобится, сколько они смогут сэкономить на наших услугах. Это опять заставило меня идти в отдел маркетинга и требовать, чтобы они все картинки положили в SAP, а мы могли бы брать оттуда необходимые изображения. В результате у маркетологов появляется задача поддерживать актуальность базы изображений, а это уже элемент культуры, привить который очень сложно. Для сотрудников отдела маркетинга, дизайнеров, художников это только лишняя работа. Но если это будет сделано, отдачу почувствует вся цепочка продаж, так что заставить их необходимо. Но я сама заставить их не могу, только через высшее руководство.
В прошлом году мы прорабатывали возможность создания электронного архива для финансового департамента. Он самый структурированный, самый организованный, и у них постоянная нужда обращаться к архиву во время судебных разбирательств. Они хотели всю цепочку от счета-фактуры оцифровать, причем автоматически. Долго разбирались, в конце концов мы сделали к своей старой системе дополнительный модуль, купили быстрые сканеры, научили их нормально сканировать и привязали к электронной накладной. При необходимости всегда можно быстро найти скан-образ документа. Ничего более сложного пока не потребовалось.
Вся наша самописная система изначально развивалась как набор документов. Потом появились статусы, рабочие процессы. Потом подключили работу с неструктурированным документом — это файл любого размера, в который можно положить все что угодно, в том числе изображения, хранится он в той же Oracle, с другими связан набором полей. И нам этого хватает практически для любых задач. Отдельно мы ведем архивы юридических и финансовых документов, это две независимые базы.
Александр Краснов: У нас такого неструктурированного контента, который производился бы систематически, нет. Служебные записки постоянно идут потоком и могут совершенно по-разному обрабатываться в СЭД. Сейчас мы заменили систему электронного документооборота и начали с этим разбираться. Пока только анализируем хождение и обработку документов, через месяц, когда появится статистика, будем думать, как можно оптимизировать связанные с ними процессы.
Владимир Панов: Согласование договоров — весьма востребованная нашими клиентами функциональность. Наиболее распространена интеграция с «1С», SAP и другими ERP. Договору соответствует учетная карточка, по ее полям устанавливаются связи.
Лидия Семичастная: Проблема согласования договоров важна и для нас. У нас более 150 «давальческих» фабрик: это независимые от нас юридические лица, но они шьют продукцию по нашим заказам из наших материалов. Условия работы меняются постоянно, договора систематически заключаются заново. К каждому договору есть приложения: что мы шьем, по каким расценкам. Это тесно связано с нашей основной самописной системой, так как именно в ней хранится вся экономическая информация. Поэтому юристы хотят видеть договора и приложения к ним. Довольно часто перезаключение договоров происходит из-за переименования контрагентов уже во время действия договора, поэтому юристы должны иметь весь архив взаимоотношений. Потребности в контекстном поиске у нас нет, поиска по полям вполне достаточно.
Олег Бейлезон: Все чаще задачи управления контентом, хранение, поиск сливаются с задачами BPM. Пока документооборот не связан с управлением процессами, если им и пользуются, то для весьма ограниченной функциональности. Нужна гибкость в настройке и перенастройке процессов, в построении интеграции и в содержании самого контента во всех этих процедурах: при его хранении, поиске, организации доступа и управлении правами на все операции. Причем все это требуется «в одном флаконе».
Сейчас, с появлением ECM-решений, совмещающих в себе BPM и Document Management, мы получаем новые возможности для решения таких задач.
Intelligent Enterprise: Взаимодействие на уровне ИТ-систем, в том числе применение электронных счетов-фактур: что подстегивает этот процесс, а что тормозит?
Александр Краснов: Взаимодействие с сетевой розницей на уровне ИТ-систем, в том числе обработка электронных счетов-фактур, у нас есть. Это очень эффективно, значительно облегчает работу. Имею в виду оформление у нас их заказа и все дальнейшие взаимодействия по нему. А вот все остальное, другие типы контрагентов и взаимодействия с ними — это очень долгий процесс, в том числе те же счета-фактуры, но в других областях. У нас ведь сорок тысяч активных контрагентов. Только в крупных контрактах мы можем другую сторону просить или заставлять переходить на новую систему расчетов — на электронный обмен документами через оператора. С другой стороны, если при общении с сетевой розницей мы получаем много заказов и много документов к ним, то есть и поставщики, где оборот большой, но документов мало — тогда зачем это взаимодействие автоматизировать?
Причем у каждого оператора свой формат. Пока между ними не будет нормально работающего роуминга, дело не пойдет. Сами операторы с самого начала, когда еще только готовился закон, озаботились этой проблемой. Но интеграция операторов подразумевает очень много нюансов, поэтому процесс еще далек от завершения. А этот «роуминг» — настоящий камень преткновения.
Крупная сетевая розница может настаивать на определенных правилах работы, обмена документами. А мы как производитель заставить десятки тысяч своих конртагентов не можем, мы в другой конкурентной среде. Поэтому сам подход с электронными счетами нам интересен, за ним, конечно, будущее, но пока еще полноценно использовать его мы не можем.
Мы ждем роуминга. Тогда мы выберем одного оператора, с которым будем работать в одном формате документов. Пока же нет роуминга — нет и стимула для нас двигаться активно в эту сторону.
Лидия Семичастная: Гипермаркеты, например «Ашан», вынудили нас использовать внешние системы ECOD для обмена данными, в том числе электронными счетами-фактурами. Нам пришлось для каждой сети хранить отдельную кодировку. Это первая проблема: товарный справочник большой, и как идентифицировать товар, если у него нет международного штрихкода?
Все поставки в сетевые магазины у нас идут через электронный документооборот и электронные платежные документы. Это действительно удобно. Все заявки, все документы по заказам в обе стороны — всё движется автоматически. Это очень важно, потому что когда логистические документы оформляются обычным образом, они часто теряются и потом в суде невозможно доказать, что они точно были. Это обуславливает необходимость строго фиксировать факт отгрузки, фотографировать машину, увозящую товар, что и как в ней лежало. Конечно, лучше бы всего этого избегать. Сейчас мы решили перейти на электронное взаимодействие со своими филиалами, которые мы точно можем заставить действовать нужным образом. Филиальную сеть мы переведем на электронные счета-фактуры в течение нескольких месяцев, хотя не исключены сложности с кодировками товаров.
Наши крупные клиенты работают в основном на SAP, и это можно использовать. Вопрос, захотят ли они переходить на такую схему работы с нами. Скорее всего мы выберем облачный сервис, и это «облако» позволит нам отправлять финансовые документы и получать уведомления о том, что они приняты. Самое приятное, что юридическая сторона при этом хорошо закрыта. В системе четко фиксируется, что финансовый документ той стороной был принят. Это защищает нас от всевозможных подлогов со стороны контрагентов.
Но, конечно, вопрос стандартизации описания товара стоит очень остро. Наверное, с крупными покупателями мы могли бы договориться, но они же постоянно выкручивают нам руки. На свой товар, который они у нас закупают, мы должны им посылать документы в их кодировке в SAP с их названием нашего товара. Значит, для каждого покупателя мы должны держать индивидуальную кодировку. Мы вынуждены в своей системе хранить дубли кодов всех товаров для всех крупных покупателей.
Кроме того, проводя операции с электронными счетами-фактурами, мы обязаны, оказывается, хранить у себя копии всех проведенных документов. Меня это неприятно удивило: оператор, через которого проходят платежи, держит архив у себя, но с нас обязанности держать второй такой же это не снимает.
Николай Гегамов: Мы работаем с небольшими европейскими фабриками и не занимаемся электронными платежами. В крупной торговой компании, когда я был ИТ-директором всей логистики и дистрибуции, мы активно применяли электронное взаимодействие. Проделана большая работа по вычищению и актуализации единого номенклатурного справочника, затем мы организовали его поддержку в этом состоянии. От всех наших покупателей мы требовали присылать нам заказы пусть и в Excel, но с наименованиями товаров точно по нашему каталогу. По логистике, по закупке мы выставляли требования. По дистрибуции и продажам — требования выставляли нам. Кто более заинтересован, тот и подстраивается. Основная проблема в переходе на электронные счета — управление номенклатурными справочниками.
Александр Балакирев: Мы, как и любое другое бюджетное предприятие, осуществляем свою закупочную деятельность в строгом соответствии с 94-ФЗ, проводя конкурсные процедуры на портале госзакупок, заключая договоры в электронном виде, с применением ЭЦП.
Оплата производится посредством системы электронного документооборота казначейства, с использованием электронных платежных документов. Большая часть нашего документооборота с исполнителями проходит через электронную торговую площадку, и регламенты здесь строго определены.
В этом смысле закон работает, и работает неплохо. Сама электронная площадка в момент запуска была сыровата, были сбои и общее недовольство, но теперь это в прошлом: она работает вполне прилично, на мой взгляд, дает реальный эффект и, надеюсь, будет развиваться.
Владимир Панов: Наши клиенты обычно используют управленческий документооборот. Финансовые документы и документы, касающиеся оплат, обычно обрабатываются в других приложениях.
Хороший пример взаимодействия на уровне ИТ-систем — государственная система межведомственного электронного взаимодействия, СМЭВ. В СЭД нашего клиента через СМЭВ приходит запрос на какие-либо документы от государственной организации. В компании-клиенте по этому запросу начинают сбор или подготовку необходимых документов. Это происходит далеко не в автоматическом режиме, но все же требуемый пакет удается сформировать в разумные сроки, после чего он опять же через СМЭВ уходит к тем, кто его запрашивал. Такие системы уже действуют на федеральном и региональном уровнях. Когда все это начиналось, проект, честно говоря, выглядел несколько фантастически и не было уверенности, что это заработает, однако все получается.
Олег Бейлезон: Когда мы работали с Software AG, то видели большой интерес со стороны вендора к применению BPM для взаимодействия контрагентов. Но построить внутренний контур относительно легко. Намного сложней договориться с контрагентом. Мы продвигали в свое время такие продукты, но заинтересовалась ими только торговая розничная сеть. В BPM-системах есть очень развитые средства работы с большим числом контрагентов, с поддержкой взаимодействия в разных форматах и многое другое, однако в любом случае требуется согласие участников, их умение и желание работать по заданным правилам.
Владимир Панов: Наведение порядка стоит денег. Выполнение договоренностей — тоже. Причем все это должно происходить в нужном темпе. Я все чаще слышу: «Главное — скорость». А если вам нужно постоянно изменять то, что хорошо упорядочено, то возникает серьезное противоречие. Постепенно в BPM-системах появляются специальные инструменты для оперативного изменения правил игры. И все же нужно всегда иметь под рукой квалифицированного специалиста для внесения изменений. Хотя даже если представить себе, что не требуется постоянно привлекать программистов, далеко не каждый пользователь сможет (захочет) самостоятельно настраивать систему так, как ему нужно прямо сейчас.
Одна из интересных тенденций сейчас — автоматизированная поддержка процессов со слабой повторяемостью. Повторяются роли людей, которые участвуют в процессе, документы, которые в нем используются, но не повторяется алгоритм процесса по шагам. Алгоритм отдается людям в управление, а вся остальная поддержка есть. Это называется «адаптивный кейс-менеджмент», и это перспективно. Какую-то повторяемость надо обеспечить, чтобы пользователям было легко, но такая упорядоченность не должна сильно ограничивать гибкость.
Причины для оптимизма
Василий Анфиногентов,
директор отделения автоматизации деловых процессов компании ФОРСПостроение системы целостной автоматизации процесса, которая охватывает его целиком, стала наиболее востребованной задачей. Существенный эффект, который получает организация от подобной сквозной автоматизации, — это увеличение скорости прохождения процессов, по нашему опыту в 10 и более раз. Второй существенный эффект (он, кстати, служит основным движителем процесса автоматизации) — повышение степени контролируемости процесса и, как следствие, возможность изменения его в лучшую сторону. По нашему опыту видно, что в ходе автоматизации приходится менять как минимум половину бизнес-процессов.
Процессный подход к управлению во многих случаях действительно оправдан и доказал свою эффективность на практике. При таком подходе ставится задача оптимизировать не отдельные функции, а бизнес-процессы, пронизывающие всю организацию. Неизбежно потребуется интеграция приложений.
Такой полноценный процессный подход — все ещё редкость за исключением случаев внедрения «тяжелых» ERP-решений. В связи с тем, что задачи, решаемые BPM, перерастают функции учета отдельных стадий процесса с фиксированным их набором, становится важным обеспечить не только прикладную функциональность, но и возможность развития системы, ее интеграции, масштабирования, расширения функциональности, непосредственную связь с системами BI и прочее.
Главная проблема при таких внедрениях — организационная, связанная с сопротивлением сотрудников, контроль над которыми усиливается. Поэтому, с одной стороны, необходимо твердое намерение руководства довести процесс до конца, а с другой — сотрудники должны иметь возможность настраивать работу «под себя». Разработанные нами шаблоны построения процессов позволяют пользователям самостоятельно настраивать их еще на стадии проектирования.
При развертывании системы мы используем принцип попроцессного внедрения на основе собственной методики ведения ИТ-проектов. При этом система представляется в виде набора сервисов, благодаря чему одновременно решается также и проблема поддержки происходящих в организации изменений. Конечно, это увеличивает трудоёмкость, но результат стоит того. Начав с одного процесса, мы охватываем целиком всю область деятельности организации, сквозь которую проходит данный процесс, и быстро выдаем результат. Время разработки и внедрения одного процесса, как правило, не превышает одного месяца. Кроме того, мы быстро получаем первый отклик пользователей, пожелания которых учитываются в дальнейшем.
Преимуществом построения BPM-системы на основе сервисной модели является сохранение инвестиций на всех этапах проекта несмотря на то, что BPM-система требует постоянного развития исходя из возникающих перед заказчиком задач.
Задача внедрения BPM — это часть создания единого информационного пространства предприятия. Меняются подходы к архитектуре, к принципам и методологии автоматизации процессов. К примеру, поставляемое ФОРС решение на платформе СУБД Oracle обеспечивает наряду со стандартными процессами типового взаимодействия исполнителей поддержку произвольных, самостоятельно настраиваемых пользователем процессов.
В качестве примера отраслевой специфики можно привести особенности внедрения BPM-системы в банке. Наиболее распространенная причина старта таких проектов — необходимость обеспечения точного соответствия изменяющимся требованиям регулятора, а именно Центрального банка России, по выпуску обязательной отчетности. Так, BPM-решение должно позволять осуществлять автоматизированный расчет обязательных нормативов банка (форма 409135), которые по сути являются инструментами риск-менеджмента. Вторая по распространенности причина — переход на процессный подход к управлению внутренними процессами как средство повышения операционной эффективности. Третья — внедрение систем автоматизированного планирования и бюджетирования на базе BPM. Ну и, наконец, в качестве четвертой причины можно назвать стремление руководства банка создать полностью интегрированную ИТ-инфраструктуру, единое информационное пространство в сложной гетерогенной среде.
Внедрение BPM-системы все чаще рассматривается заказчиками не как самостоятельный проект, а как часть более масштабной задачи по созданию эффективной системы управления бизнесом. И это внушает оптимизм.
Задачи дня
Наталья Храмцовская,
ведущий эксперт по управлению документацией ООО «Электронные Офисные Системы», эксперт ИСО, член Гильдии управляющих документацией и международной ассоциации ARMA InternationalМне как консультанту приходится решать те вопросы автоматизации управления документами и информацией, с которыми ИТ-специалисты самостоятельно, как правило, не справляются. В основном это помощь организации в формировании концепций и решение конкретных правовых и организационных проблем. Все чаще организациям требуется помощь в налаживании смешанного документооборота, в который вовлечены как бумажные документы, так и электронные, как структурированные, так и слабоструктурированные и неструктурированные. Преимущественно это текстовые, графические и аудиовизуальные документы и материалы. В последнее время довольно много приходится заниматься вопросами документирования деятельности организации в социальных сетях.
Внедрение электронных счетов-фактур подстегивают, с одной стороны, собственные деловые интересы ряда коммерческих организаций, а с другой — то, что налоговая служба видит здесь возможность ужесточить контроль над оборотом счетов-фактур. Ещё одним стимулирующим фактором является растущая общая готовность организаций к использованию информационных технологий и электронных документов. Что касается факторов сдерживающих, то для подавляющего большинства организаций переход на использование электронных счетов-фактур не обещает быстрой существенной экономической отдачи и при этом связан с определенными рисками, прежде всего тогда, когда организация пытается получать возмещение НДС «относительно честными способами». Кроме того, пока не до конца ясно, как электронные счета-фактуры будут приниматься налоговыми органами.
Еще одна проблема — это обеспечение сохранности документов, поскольку типичный для счетов-фактур пятилетний срок хранения является довольно длительным для электронных документов и за это время не только заканчивается срок действия сертификата ключа электронной подписи, но и вполне может прекратить свою деятельность удостоверяющий центр или же устареть информационная система, обеспечивающая хранение электронных счетов-фактур.