Филиппов Н.Б., Обиденый Г.В.
Сервисная компания занимается техобслуживанием, ремонтом и поверками приборов специального назначения. В течение календарного месяца в компании выполняется более тысячи сервисных работ по десяткам подрядных договоров, в работе задействовано более сотни специалистов из различных служб и подразделений. Ранее указывалось, что в компании велся разрозненный учет договоров, объектов обслуживания, работ в том виде, как его понимали в каждом подразделении. Без серьезной автоматизации работа специалистов предприятия превращалась в бесконечные авралы и была большой головной болью для руководства. На предприятии предпринимались неоднократные попытки автоматизировать данный процесс, но результаты были неутешительными. Причина заключалась в том, что в те моменты не нашлось людей, способных охватить весь процесс в целом, создать единую и непротиворечивую структуру связей, чтобы она была бы одновременно удобной и простой на каждом участке работы.
Мы в свою очередь смогли подобрать нужные «ключики» к этому тяжелому замку. Как нам удалось это сделать?
Вначале мы собрали все службы вместе и просто выслушали то, как и что они делают на своем участке по каждому виду работ (техобслуживание, ремонт и поверка). По результатам этих встреч мы нарисовали бизнес-процессы и прошлись по ним со специалистами еще раз, находя противоречия и нестыковки. Мы просто их записывали, не пытаясь решать на месте – нужно было найти системное решение всей задачи, а не навешивать локальные заплатки на каждой коленке.
Затем мы сами провели оптимизацию каждого процесса, сделали унификацию документооборота и видов операций, а также систематизировали правила перехода процессов с операции на операцию.
Предложенную модель мы еще раз обсудили с заказчиком, ответили на вопросы. В этот момент наша система прошла проверку на масштабируемость и устойчивость: заказчик вдруг вспомнил про работу, которая не рассматривалась ранее. И мы, используя нашу систему, в режиме реального времени показали, как можно легко и просто достроить существующий процесс.
Как работает наша система? Что является её основной идеей?
Для удобства рассмотрения системы мы используем прием аналогии. В качестве аналога мы предлагаем рассмотреть сервисные работы в виде системы по доставке грузов в различные точки страны. Объекты обслуживания в этом случае являются аналогами грузов, которые нужно доставить из точки А в точку Б. Каждый груз становится не просто грузом, а объектом доставки с определенными параметрами: владелец, объем, вес, состояние, адрес отправления и адрес назначения. В зависимости от адреса, и параметров груза определяется маршрут доставки и виды транспорта, которыми будет осуществляться доставка: автомобиль, поезд, пароход, самолет. Вид транспорта – это выполняемый вид операции, доставка может выполнятся в несколько этапов, используя склады и перевалочные пункты с одного вида транспорта на другой.
Важно отметить, что в процессе доставки может поменяться состояние груза (отметка в приёмочном документе) и тогда этот груз перейдет на определенный склад перевалочного пункта – адрес хранения. От адреса хранения зависит куда и чем будут доставлять груз. На перевалочных пунктах осуществляется планирование – происходит сборка грузов в один транспорт (работа бригады, инженера за один день-неделю и т.п.). В процесс мы можем вводить склады, с которых осуществляется возвращение груза назад в нужный пункт. Такой груз доставляет специальный транспорт. Всё это позволяет нам развязать грузы и транспорт. Чтобы узнать статус груза (статус объекта), нужно получить текущее место его нахождения: в пути (наименование транспорта) или на складе перевалочного пункта (наименование склада). В этом случае нам всё равно чем и как доставлялся груз до этого места. Для анализа динамики процесса можно хранить историю статусов.
Этот подход позволяет нам установить чёткий порядок передачи груза из пункта на транспорт и наоборот. В зависимости от типа транспорта (конечное число значений) определяется тип сопроводительных документов и набор их параметров. Груз доставлен (отгружен) – документы подписаны, статус груза изменился.
Всё работает, всё занимает своё место. Хранением груза занимаются кладовщики, перемещением – диспетчеры. Таким образом, при независимой работе транспортных бригад на отдельных участках достигается слаженная эксплуатация и качественное управление всем процессом доставки грузов.
Для наглядности метода кратко опишем два производственных процесса: техническое обслуживание и ремонт.
На рисунке 1 показана схема процесса «техобслуживание», а на рисунке 2 схема процесса «ремонт».
Рисунок 1. Схема процесса «Техобслуживание»
Каждый блок на рисунках 1 и 2 – это производственная операция. Одна и та же операция может входить в несколько производственных процессов. Например, операция планирования может быть и частью процесса технического обслуживания, и одной из начальных операций процесса ремонта.
Рисунок 2. Схема процесса «Ремонт»
Все производственные операции можно описать с помощь 8 типов документов:
1) заявка на работы – инициализация процесса;
2) план работ;
3) задание на работы – наряды исполнителям;
4) акт выполнения работ (внутренний);
5) акт приёмки-передачи объекта (внутренний);
6) акт приёмки-передачи объекта (внешний);
7) акт согласования работ (с заказчиком) – виза на инициализацию другого процесса;
8) акт выполнения работы (с заказчиком).
Для удобства описания, операции на рисунках 1 и 2 пронумерованы по типам, а однотипные операции имеют одинаковый цвет.
Рассмотрим особенности отдельных типов операций (документов).
Документ «Заявка на работы».
Как видно из рисунков, сервисная компания использует заявки как на техобслуживание, так и на ремонт. Это значит, что в документе «Заявка на работы» должно быть уточнение по типу производственного процесса, в данном случае, «Техобслуживание» или «Ремонт на месте».
Кроме того, в процессе ремонта (рисунок 2) кроме заявок на ремонт используются также заявки на демонтаж (блок 1.3). Это значит, что в документе «Заявка на работы» уточнения по типу производственного процесса недостаточно, требуется также уточнение по виду операции, в данном случае, «ремонт на месте» или «демонтаж».
На принадлежность документа «Заявка на работы» к определённому договору указывают организация, контрагент и договор.
Итак, основной набор определяющих документ (не только «Заявка на работы») реквизитов выгляди так:
- номер;
- дата;
- организация;
- контрагент;
- договор;
- период работ;
- тип процесса;
- вид операции.
Наконец, блоки 1.1 и 1.2 на обоих рисунках указывают на то, что документ «Заявка на работы» проходит несколько стадий. Сотрудник, ответственный за уточнение заявки, не имеет доступ к документу «Заявка на работы» на стадии оформления (разделение зон ответственности). Аналогично, сотрудник, занимающийся планированием заявок, не имеет доступ к документу «Заявка на работы» на стадии уточнения.
Для разделения и определения уровня доступа к данным в системе разработаны роли, а в документах установлены статусы. Например, документ «Заявка на работы» имеет статусы «Предварительная», «В работе» и «Завершена». Для первых двух статусов разрешено редактирование данных, но для разных пользователей. Для статуса «Завершена» редактирование данных заявки запрещено, а заявка доступна для планирования.
Состав и порядок статусов документов, а также доступ пользователей к документам и разрешённые действия с данными, детализированные до статуса документа, могут быть настроены пользователем с правами администратора.
Документ «План работ».
Документ «План работ» имеет ряд особенностей, делающих его самым сложным документом системы сервисного обслуживания. Вот некоторые из этих особенностей:
1). в документе «План работ» объединены объекты обслуживания по разным контрагентам, договорам и даже типам производственных процессов. Объект обслуживания попадает из заявки в план не по типу производственного процесса, а по более сложному алгоритму: ответственный -> подразделение ответственного -> типы производственных процессов, обслуживаемые подразделением -> объекты заявки по обслуживаемому подразделением типу процесса.
Следствием является то, что в планах нет разделения зон ответственности. Сотрудники (как правило, это руководство подразделений), занимающиеся планированием, имеют доступ и к планам других подразделений. Так задача планирования была поставлена сотрудниками сервисной компании.
2). в документе «План работ» происходит распределение объектов обслуживания по исполнителям. Это распределение может быть как автоматическим (объекты закреплены за исполнителями), так и ручным (объекты закреплены за лицом, отвечающим за доступ к объектам; по исполнителям их нужно разносить). Вариант распределения указывается в реквизите «Вид операции».
3). документ «План работ» допускает как частичное пополнение (объектами вновь появившихся заявок), так и частичное исключение из дальнейшего планирования (объектов по сформированным на основе плана заданиям (нарядам)). В этом смысле документ «План работ»можно сравнить с бассейном, который имеет входную и выходную трубу.
Документ «План работ» имеет всего два статуса: «В работе» и «Завершен». Весь функционал планирования доступен в статусе «В работе»; в статусе «Завершён» доступен только просмотр документа.
Документ «Задание на работы».
Документ «Задание на работы» достаточно прост. Он создаётся либо на основе Акта (одно задание по одному Акту, блоки 4.2 и 4.7), либо на основе плана (много заданий по одному плану, блоки 2, 2.1, 2.2, 2.3).При создании заданий на основе плана задания детализируются до договора, даты, исполнителя и адреса.
Одной из основных функций документов «Задание на работы» является выдача сопровождающей наряд документации. К этой документации могут относиться наряд на работу, Акт о выполнении работы. Факсограмма об обеспечении доступа на объект должна быть подготовлена и передана Заказчику по договору за несколько дней до выполнения задания. Путевой лист на день, передаваемый исполнителю, относится не к отдельному документу «Задание на работы», а включает информацию всех документов «Задание на работы» по конкретному исполнителю и дате и содержит как чистое время обслуживания объектов, так и время перемещения исполнителя между объектами обслуживания. Все печатные формы подключаются к документу «Задание на работы» через механизм подключения печатных форм, который позволяет разрабатывать и делать доступными пользователям специализированные печатные формы для разных типов процессов, видов операций, договоров контрагентов и других условий.
Документ «Задание на работы» имеет три статуса: «Предварительное», «В работе» и «Завершено». Статус «Предварительное» предназначен для подготовки выполнения задания; в этом статусе доступно редактирование данных задания. Статус «В работе» предназначен для создания документа «Акт выполнения по заданию» на основании документа «Задание на работы». В статусе «В работе», как и в статусе «Завершён», доступен только просмотр документа «Задание на работы».
Документ «Акт выполнения работ (внутренний)».
В сервисной системе присутствуют аж шесть разных вариантов документа «Акт выполнения работ (внутренний)»: 1). Акт обследования объекта на месте; 2). Акт демонтажа; 3). Акт диагностики и дефектовки; 4). Акт ремонта; 5). Акт освидетельствования и 6). Акт монтажа. Конкретный вариант документа указывается в реквизите «Вид операции».
Как правило, Акты имеют подписи и печати сторон.Достаточно важной задачей документа «Акт выполнения работ (внутренний)» является хранение произвольного количества прикреплённых документов (в частности, сканов Актов).
Другой важной задачей документа «Акт выполнения работ (внутренний)» является организация ветвления производственных процессов на основе результата работ «Акта выполнения работ (внутренний)». Например, из блока 4.2. на рисунке 2 обозначены переходы к блокам 3.1., 3.2., 1.3. и 8.1., а результаты работ указаны на стрелках переходов.
Документ «Акт выполнения работ (внутренний)» имеет два статуса: «Предварительный» и «Исполнен». Вся работа с документом «Акт выполнения работ (внутренний)» осуществляется в статусе «Предварительный». Например, в этом статусе доступно указание результата работ и создание документов на основании документа «Акт выполнения работ (внутренний)». Если бы доступ к этим операциям надо было бы разделить, пришлось бы вместо статуса «Предварительный» сделать два (например, «Предварительный» и «В работе»). В статусе «Завершён» доступен только просмотр документа «Акт выполнения работ (внутренний)».
Документ «Акт приёмки-передачи объекта (внутренний)».
Документ «Акт приёмки-передачи объекта (внутренний)» проще документа «Акт выполнения работ (внутренний)» в следующих аспектах:
1). так как это внутренний документ, подписанный Акт приёмки-передачи можно не прикреплять к документу;
2). нет ветвления процесса после документа «Акт приёмки-передачи объекта (внутренний)».
Документ «Акт выполнения работ» имеет два статуса: «Предварительный» и «Исполнен». Создание документа (акта диагностики или акта монтажа, в зависимости от вида операции) на основании документа «Акт приёмки-передачи объекта (внутренний)» осуществляется в статусе «Предварительный». В статусе «Завершён» доступен только просмотр документа «Акт приёмки-передачи объекта (внутренний)».
В документе «Акт приёмки-передачи объекта (внутренний)» возможны также особые операции, например, присвоение объектам обслуживания внутренних номеров.
Документ «Акт приёмки-передачи объекта (внешний)».
В документе «Акт приёмки-передачи объекта (внешний)» необходимо прикрепление подписанного Акта приёмки-передачи к документу, как в документе «Акт выполнения».
В документе «Акт приёмки-передачи объекта (внешний)» нет ветвления процесса после документа, как в документе «Акт приёмки-передачи объекта (внутренний)».
Особенностью документа «Акт приёмки-передачи объекта (внешний)» является то, что объект обслуживания может быть заменён производителем, чего нет больше нигде в системе сервисного обслуживания.
Статусы «Предварительный» и «Исполнен» документа «Акт приёмки-передачи объекта (внешний)» аналогичны статусам документов «Акт выполнения» и «Акт приёмки-передачи внутренний».
Документ «Акт согласования работ (с заказчиком)».
Документ «Акт согласования работ (с заказчиком)» несложен, но имеет несколько интересных особенностей:
1). производственный процесс переходит на сторону Заказчика по договору, и продолжительность этого перехода часто не регламентируется договором, так что процедуру согласования надо контролировать;
2). после документа «Акт согласования работ (с заказчиком)» производственный процесс может разветвляться в зависимости от результата согласования (см. блок 7.1 на рисунке 2);
3). после документа «Акт согласования работ (с заказчиком)» производственный процесс может закончиться и, в зависимости от результата согласования, перейти в другой производственный процесс (см. блок 7 на рисунке 1). В целях правильной идентификации объектов обслуживания необходимо сопоставлять получаемые от Заказчика по договору заявки и ранее оформленные с ним согласования.
Документ «Акт выполнения работы (с заказчиком)».
Оформление актов выполнения работ по договору – это самый трудоёмкий этап производственных процессов сервисного обслуживания.
Документ «Акт выполнения работы (с заказчиком)» проходит следующие статусы: «Предварительный», «Согласован», «Подписан», «Завершён».
На статусе «Предварительный» в документ «Акт выполнения работы (с заказчиком)» собираются данные входящих в него документов «Акт выполнения работы (внутренний)». Этот процесс похож на получение данных в заявку на работы или в план.
Также на статусе «Предварительный» формируется комплект документов для Заказчика по договору. Некоторые документы этого комплекта (в основном, заявки, различные Акты и Свидетельства) готовы и собираются из различных документов производственного процесса. Многие печатные формы (общие дефектные ведомости, реестры резервируемых номеров общих Актов о приёмке услуг, общие Акты о приёмке оказанных услуг, Акты по форме КС-2 с приложениями, Справки стоимости выполненных работ по форме КС-3, Сметы по ТСН 2001 и др.) прикрепляются к документу «Акт выполнения работы (с заказчиком)». Все входящие в комплект документы необходимо разработать в соответствии с шаблонами и методиками заполнения, закреплёнными в договоре с контрагентом.
На статусе «Согласован» подписанный со стороны Исполнителя по договору комплект документов передаётся для подписания Заказчику по договору. С этого момента документ «Акт выполнения работы (с заказчиком)» доступен только для просмотра. Происходит мониторинг процесса подписания комплекта документов Заказчиком по договору.
На статусе «Подписан» подписанный со стороны Заказчика по договору комплект документов возвращается Исполнителю по договору.
После регистрации Исполнителем по договору и выполнения всех предусмотренных регламентом действий документ «Акт выполнения работы (с заказчиком)» переводится в статус «Завершён».
Итак, проведённый анализ производственных процессов сервисного обслуживания позволяет сделать вывод о том, что с помощью предложенных в статье инструментов возможно распределение зон ответственности по ролям исполнителей и тем самым эффективная автоматизация этих процессов.
Как мы уже отмечали ранее, автоматизация данной задачи превратилась в обычный рутинный процесс. В качестве базовой платформы мы использовали решение «1С:ТОИР». В результате разработки мы смогли создать достаточно универсальный продукт, который может настраиваться на пользовательском уровне:
- конструировать бизнес-процессы, создавая связи между документами и статусами объектов;
- к документам можно подключать внешние печатные формы;
- документы подсистемы могут связываться с типовыми документами «1С:ТОИР»;
- настраивается доступа пользователей к документам и отчетам бизнес-процессов.
В результате получился достаточно универсальный продукт для автоматизации любой сервисной компании. А в данном конкретном случае мы успешно завершили опытную эксплуатацию автоматизированной системы.
