На 8 минут быстрее

Какие цели?

В структуру нефтехимического холдинга СИБУР входит многофункциональный сервисный центр, который называется «СИБУР Центр обслуживания бизнеса» (СИБУР-ЦОБ). Подразделение, по сути, представляет собой бэк-офис и оказывает другим предприятиям холдинга услуги в области экономики и финансов, бухгалтерского и налогового учета, информационных технологий, управления персоналом, документационного и информационного обеспечения.

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

Исполнителям, а именно сотрудникам ЦОБ, необходимо работать в общем удобном для всех интерфейсе, иметь прозрачную отчетность и гибкие дашборды .

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

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

Предпосылки изменений:

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

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

• В некоторых отделах обращения распределялись вручную.

• Заявки, поступающие по телефону, часто не регистрировались.

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

подробнее

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

• учитывать 220 процессов заказчика;

• обеспечивать одновременную работу 20 тысяч сотрудников в роли заказчиков, и 3 тысяч — в роли исполнителей;

• быть совместима с другими существующими информационными системами СИБУРа и предоставлять возможность создавать отчеты;

• гибко и просто менять уже реализованные бизнес-процессы ;

• иметь красивый и удобный интерфейс и возможность работы с мобильных устройств.

Agile и Open Source

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

Поэтому решили использовать Open-Source-продукт и дорабатывать его функционал с учетом потребностей СИБУРа. За основу взяли систему Process Maker с готовым базовым функционалом и открытым исходным кодом. Из плюсов такого ПО: не нужно платить за поддержку, можно легко и в короткие сроки на любом этапе что-то доработать, внедрить новые функции. Для этого не нужно подписывать новый договор, составлять ТЗ и согласовывать тонну бумаг. К тому же удобно всегда держать руку на пульсе.

«Мы держим вектор на развитие внутренней перспективы, так что единственный минус — необходимость собственного штата экспертов — нас не напугал, — поделился Сергей Васильев, руководитель направления «Информационные технологии и бизнес информация» ООО «СИБУР ИТ». — В частности, мы ориентировались и на опыт других крупнейших компаний, из которых порядка 65% внедрили ПО, которое возможно развивать своими силами. Process Maker, к примеру, используют Toyota, Lenovo и GTBank».

Рассмотрим коротко основные преимущества ПО с открытым кодом:

• Бесплатные продукт и его сервисы (в том числе лицензии и поддержка).

• Готовый базовый функционал и мобильная версия имеющегося решения.

• Встроенный конструктор процессов позволяет заказчику самостоятельно отрисовывать процесс в целевой системе и формировать для него условия.

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

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

Проектная команда работала при помощи Scrum. В качестве информационной системы по внедрению нового продукта использовали Jira . В проекте команда работала по Kanban доске. Спринты были достаточно короткие: сначала одна неделя, потом команда увеличила до двух.

Гибкие методики разработки

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

SCRUM, несмотря на то, что появился немногим раньше, чем Agile, является его отдельным подходом. Суть его заключается в том, что проекты, над которыми работают небольшие обособленные команды специалистов различного профиля, обычно систематически производят лучшие результаты. Главное преимущество заключается в концентрации внимания на целях, из которых выделяются уже вполне определенные задачи. 

подробнее

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

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

Анатолий Белайчук 
президент Ассоциации профессионалов управления бизнес-процессами

Результаты

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

Сегодня команда проекта автоматизировала только пятую часть процессов. Это только начало. При завершении проекта СИБУР планирует:

1. повысить эффективность подразделения на 20%;

2. организовать единое окно для всех сотрудников;

3. обеспечить возможность ведения прозрачных отчетов и удобные дашборды;

4. описать все процессы ЦОБ в единой методологии и привести наибольшее количество процессов к стандартным шагам.

Советы и выводы

Проект связан с трудностями и проблемами, с которыми команда СИБУРа пока справляется. Сергей Васильев поделился некоторыми советами, которые могут пригодиться компаниям, планирующим внедрять BPMS-систему:

• BPM-решения предназначены для автоматизации «несложных процессов». Не все процессы можно автоматизировать с помощью BPMS;

• BPM-решения не создают процесс с нуля. Для автоматизации процесс должен быть описан;

• как правило, любая BPM-платформа требует «кастомизации» . В ином случае приходится мириться с ее ограничениями;

• вовлечение ИТ — обязательное условие. BPM-решений, которые меняют процессы только с помощью бизнес-пользователей, не существует.

Именно из этих советов СИБУР сформировали для себя основные выводы по результатам проекта:

1. Функционально нет разницы между платными и бесплатными BPM-решениями. В компании с внутренним штатом ИТ-специалистов необходимо использовать бесплатные BPM-решения.

2. Необходимо развивать внутреннюю экспертизу по BPM как со стороны ИТ, так и со стороны бизнес подразделений.

3. Нет необходимости стремиться к одному BPM-решению внутри компании. Различные BPM-продукты имеют разную специализацию. Использование нескольких BPM, которые разделены по функциональным зонам, логично и правильно.

Благодарим за предоставление материалов ABPMP Russian Chapter и лично Анатолия Белайчука.