Диагноз — Excel головного мозга. Как бороться и автоматизировать бизнес с наименьшим препятствием участников процесса

Сергей Локотков, (skillstudio.top), ведущий специалист по внедрению ELMA BPM одного завода

Существует проблема – хранение информации в Excel таблицах во множестве таблиц в разных разрезах у разных сотрудников и руководителей. Собрать из них информацию в общую картину зачастую невозможно. Борьба с эксельками и систематизация информации — одна из проблем, которую приходится решать при внедрении BPM-системы. Решаю её и я. В процессе реализации единого реестра платежей в компании столкнулся с интересной проблемой – вторичный эксель.

Как было дело

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

Было 2 вида проблем: отсутствие сведений об оплатах вовремя и невозможность оценить объем задолженности быстро. Был реализован процесс «Оплата входящего счета». Процесс принимал от пользователя документ и информацию (вид оплаты, вид сделки, сроки оплаты и др). Происходило согласование с ответственными лицами и далее процесс регистрировал оплату в справочник в ELMA. Это позволило искоренить разнородные эксельки на местах, и появился единый реестр платежей. Казалось бы, Happy end.

Но потом началось интересное явление. Люди на местах, те самые, что вели свои реестры платежей, вместо того, чтобы пользоваться фильтрами по справочнику, начали вести реестры ссылок на записи справочника у себя в эксельках. А чуть позже перешли на прогрессивный формат – гугл таблицы, и сделали общую таблицу ссылок на справочник в ELMA. Причем, это выяснилось случайно. Все были довольны единым реестром платежей в ELMA, но работали с ним через гугл таблицу. Позже удалось выявить причину: зачем им нужна эта таблица.

Оказалось, что с помощью таблицы согласовывали с бухгалтерией оплату счетов. Например, сегодня в оплату идут платежи с 20 по 25 строку, завтра с 25 по 52. После оплаты ссылки из таблицы удалялись. Решено было реализовать статусы и портлеты по статусам. В справочнике ставятся статусы, а портлеты отображают, что и когда оплачивать. После оплаты бухгалтер отмечает в портлетах, какие платежи были проведены, статус платежей автоматически меняется. Пока наблюдаем, не придумают ли еще какой-нибудь ексельки её пользователи… Есть мысль пойти дальше и реализовать интеграцию с 1С в части заведения платежек, но пока это только мысли.

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

На первом шаге был реализован процесс «Заявка на расчет», где требовалось указать все входные параметры, а в ответ получить расчет и цену. Стало лучше, но у КТО не было понимания, какую заявку делать в первую очередь. В отделе продаж 20-40 человек, и у каждому необходим расчет. У КТО висит обычно около 15 расчетов в очереди.

На втором шаге реализовали приоритеты: низкий, средний и высокий. Установку приоритета согласовывает коммерческий директор в зависимости от срочности. Казалось бы, отличное решение из очереди в примерно 15 штук, 5 будет с высоким приоритетом и всё будет хорошо. Но на практике оказалось, что 80% очереди уходит в высокий приоритет. А вот третий шаг пока не придумали. Что делать с перегрузом заявками с высоким приоритетом пока не понятно. Будем думать… Идеи принимаются в комментарии, как говорят блогеры на ютубе) А где же табличка – а табличка это 3 фильтра по экземплярам процесса по приоритетам. Но в итоге так, как почти все свалилось в высокий приоритет, толку от неё пока не много. Вообще различных фильтров у нас много. Интерфейсное решение с портлетами-фильтрами очень сильно может упрощать жизнь конкретному пользователю. Особенно если его научить выводить данные в портлеты-фильтры самостоятельно.

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

Что было сделано – мы реализовали 3 процесса для разных крупных подразделений со своей спецификой.

В целом процессы похожи, но отличаются деталями. Решили разделить, так как большой процесс с множеством ветвлений сложно поддерживать. Лучше сделать много маленьких и построить цепочку из подпроцессов. Ядром всех командировок является процесс «служебная записка», где расписано: кто, когда, куда и необходимые затраты. Это центральный подпроцесс. В начале вообще только он и был. Но кроме самой служебки важно согласовать целесообразность выезда и некоторые детали в начале и получить авансовый отчёт и отчёт о результатах командировки в конце. Вот тут-то и были проблемы — учет велся руководителями подразделений в разных форматах.

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

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

Без сдачи отчета о командировке, система не выпустит в следующий выезд.

В результате имеем

Все ли проблемы решены? Нет, в процессе эксплуатации был выявлен ряд проблем. Но о них, наверное, в следующий раз.

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

Ну и одна из основных причин, зачем бороться с эксельками, та же, что и польза внедрения ELMA, — решение проблемы незаменимости. Если кто-то на месте ведет сложную таблицу, от которой зависит почти все, и она так хитро устроена, что только он может ее читать. В общем, это опять способ создания незаменимого человека. А ведь человек может уйти внезапно… А вместе с ним ваш бизнес? Я драматизирую, но проблем можно получить немало, если теряется какой-нибудь властелин екселя, управлявший через него вашим складом готовой продукции, доставками и предзаказом. Ну не знает он 1С или дорабатывать ее некому и дорого. Ну и ведет в экселе ну и хорошо уже 10 лет как. Или нет?

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

По поводу отчетов мы вообще отказались от модуля «Отчеты» в ELMA и формируем все выгрузки в виде Excel таблиц по тем самым согласованным со всеми участниками процесса формам. Но про отчёты и про то? почему выгрузка в Excel лучше, чем модуль отчётов в ELMA, в следующей серии.