| | Бизнес-конвейер. Практика использования состояний документов при автоматизации документооборота сервисного центраИзвестно, что конвейер изобрел Генри Форд.
Велосипед может изобрести кто угодно.
Кем и когда придумано движение документов по инстанциям до сих пор доподлинно неизвестно, однако на нем и основано современное делопроизводство. Запрос на некое действие, связанное с каким-то объектом (изначальный документ), поступает в канцелярию и отправляется в движение по инстанциям. Каждая инстанция — специалист в какой-то области, задача специалиста — изучить запрос со своей точки зрения и произвести какие-то действия, после чего передать запрос на следующую инстанцию. В зависимости от каких-то условий и действий очередного специалиста объект и запрос могут как-то меняться, к изначальному документу могут добавляться дополнительные. Какова будет очередная инстанция, и что там нужно будет сделать, напрямую зависит от действий предыдущих инстанций и изменений объекта и сопровождающих документов. Цепочка завершается, когда с объектом сделано все, что возможно (нужно, положено, разрешено) сделать, и когда выпущены все необходимые документы. Добавим к этому, что деятельность имеет конкретную цель, запросов и объектов много, а действия специалистов с объектом и документами регламентированы — в результате получится то, что сейчас принято называть деятельностью, основанной на бизнес-процессах. Примером такой деятельности могла бы стать работа государства, если бы она была нацелена на удовлетворение потребностей граждан.
Велосипедом, подлежащим изобретению, для автора стала автоматизация бизнес-процессов одного из сервисных центров (СЦ), занимающегося ремонтом офисной, бытовой, компьютерной и периферийной техники.
Этот СЦ — мультибрендовый, имеет авторизации более чем по 50 брендам, в том числе: ASUS, SONY, DELL, LENOVO, TOSHIBA, NEC и др. Он имеет в штате более 20 сотрудников и проводит как гарантийный, так и платный ремонт. Для ведения учета была выбран программный пакет „Управление сервисным центром для 1С: Предприятие 8». Основной задачей автора было проектирование современной системы управления предприятием, оптимизация бизнес-процессов компании, и, самое главное — внедрение всего этого на практике. Именно на этапе внедрения и появилась достаточно интересная идея, про которую и пойдет речь дальше.
Рассмотрим упрощенную схему бизнес-процессов, связанных с приемкой изделия в ремонт и заказом для него запасных частей (рис. 1).
Рис. 1. Алгоритм работы СЦ
В момент обращения клиента выясняется, считает ли клиент ремонт платным или гарантийным. В первом случае производится приемка изделия с типом работ — „платный». Если речь идет о гарантийном ремонте, то в присутствии клиента проверяется „гарантийность» по серийному номеру изделия. Серийный номер прямо указывает на дату выпуска и, в случае, если гарантийный срок с момента выпуска не истек, производится приемка изделия с типом работ „гарантия производителя». В ситуации, когда гарантийный срок с момента производства истек, а с момента продажи — еще нет, производится „временная» приемка с типом работ „проверка гарантийности». Проверка осуществляется путем запроса производителю с вложением копий документов о покупке и, в зависимости от производителя, может занять несколько дней. По результатам проверки производится либо приемка изделия с типом работ „гарантия производителя», либо возврат изделия клиенту (клиент может оформить платный ремонт, если захочет).
После приемки изделие поступает на диагностику. В случае если ремонт может быть произведен без использования запасных частей, мастер его выполняет и сдает изделие на выдачу. Если запчасти для ремонта нужны, мастер составляет спецификацию и выпускает один из двух документов: внутренний заказ для гарантийного ремонта или калькуляцию для платного ремонта. Если калькуляция согласовывается, утверждается и, при необходимости, оплачивается клиентом, то на ее основании создается документ „Внутренний заказ», если нет — изделие возвращается клиенту без ремонта.
Наличие внутреннего заказа является для службы склада и логистики основанием для получения или приобретения запчастей. После их получения ремонт возобновляется, завершается, и изделие поступает на выдачу.
На рис. 1 выделены отдельные подразделения сервисного центра, в каждом из которых работает несколько человек. Видно, что деятельность по заказу в зависимости от различных условий переходит от одной инстанции к другой и схема передачи ответственности далеко не линейная. Кроме того, часть процессов (приемка-выдача, подтверждение гарантии, согласование цены и поставка ЗИП) связана с внешними контрагентами — клиентом, производителем и поставщиком. Не упрощает ситуацию и то, что время наступления очередного события является случайным. Например, необходимость согласования цены может возникнуть тогда, когда на приемке скопилось несколько клиентов для сдачи или получения техники.
Требуется: обеспечить выполнение необходимых действий по каждому изделию, минимизировать время их выполнения с учетом приоритета очного обслуживания клиентов, согласовать взаимодействие служб, исключить ошибочные и повторные действия.
Конфигурация „Управление сервисным центром» предоставляет достаточно удобный механизм для организации документооброта в СЦ. Документ-объект (к примеру, заказ-наряд) может переходить в заранее определенные состояния в зависимости от проведения какого-либо документа-повода и выполнения некоторых условий. Например, проведению документа-повода „Акт выполненных работ» может быть назначено изменение состояния документа-объекта „Заказ-наряд» на „Выдавать по оплате» для платных работ и „Можно выдавать» — для гарантийных. Смена состояний происходит автоматически. В момент проведения документа-повода производится проверка соответствия указанных реквизитов документа-повода или документа-объекта заданным условиям и, по результатам проверки, производится (или не производится) изменение состояния документа-объекта на состояние, указанное в настройках. Для каждого документа может существовать несколько групп (схем) состояний, что позволяет настроить эти схемы под потребности отдельных подразделений. Например, движение заказ-наряда можно отслеживать с точки зрения приемки, ремонтного цеха и службы склада и логистики и отображать те состояния, которые интересуют именно эту службу. Так, мастеру важно знать, что есть изделие, подлежащее диагностике и ремонту, что на склад поступили заказанные им запчасти, а информация по согласованиям и заказам его будет лишь отвлекать. Логистику важно знать, что требуется заказ неких запчастей, а приемке нужна укрупненная информация по ходу согласований и ремонта.
Решение: использовать систему состояний документа „заказ-наряд» для упорядочивания бизнес-процессов в процессе приемки, выяснения гарантийности, согласования цены и получения запчастей для ремонта.
Рис. 2. Окно программы 1С: Предприятие — Управление сервисным центром
При использовании состояний список документов можно раскрасить в соответствии с текущим состоянием, либо указать системе на необходимость распределить документы по соответствующим закладкам (см. рис. 2). Например, если для некоего заказ-наряда был создан документ „Внутренний заказ», то этому заказ-наряду автоматически присваивается состояние „Ожидание ЗИП». В этом случае служба склада и логистики может увидеть этот заказ-наряд на одноименной закладке. После чего предпринять необходимые действия по заказу, оплате и доставке запчастей.
Идея: использование схемы состояний для управления бизнес-процессами.
Собственно, суть статьи и придуманный автором „велосипед» заключается в следующих предложениях:
– сотруднику назначается контроль за документами, имеющими определенное состояние (или несколько определенных состояний);
– сотрудник должен предпринимать действия для перевода документа в следующее состояние (опустошать закладку контролируемого им состояния);
– эффективность работы сотрудников определяется количеством документом, оставшихся в его зоне ответственности в контролируемом состоянии (чем меньше, тем лучше).
Например, чтобы освободить закладку „Согласовать цену», сотрудник (оператор) должен будет провести калькуляцию с состоянием „согласована». Он не сможет сделать этого, пока не свяжется с клиентом и не получит от него согласие или (в отдельных случаях) предоплату. После проведения калькуляции со статусом „Согласована» заказ-наряд покидает закладку „Согласовать цену» и оказывается на закладке „Ожидание ЗИП». Бизнес-конвейер распределяет документы по рабочим местам сотрудников.
Еще один пример. Мастер видит на своем рабочем месте (закладка „новый») очередной заказ-наряд (их может быть несколько), делает диагностику и составляет калькуляцию. Заказ-наряд исчезает с этой закладки (мастер сделал свое дело) и попадает на закладку „согласовать цену». Приемщик, освободившись от клиентов в зале, заходит на закладку „согласовать цену» и видит там накопившуюся для него работу. Он обзванивает, согласовывает, проводит согласованную калькуляцию. Бизнес-конвейер несет заказ-наряд дальше — на закладку „Требуются ЗИП», которая находится уже в зоне ответственности службы склада и логистики. Для приемщика заказ-наряд ждет результатов на закладке „Ожидание ЗИП».
Каждая закладка может быть назначена зоной ответственности для одного сотрудника или для подразделения. Например, в службе склада и логистики СЦ работают Игорь и Николай, которые могут работать вдвоем или подменять друг друга. Закладку „Требуется ЗИП» они расчищают, производя заказы каждый по своей группе поставщиков. Однако если в какой-то день работает лишь один Игорь, то он ведет работу за двоих. Николай, придя на следующий день, видит — какая часть его работы сделана Игорем, а какую осталось выполнить ему самому.
На рис. 3 можно увидеть предложенную и реализованную схему изменения состояний.
Рис. 3. Реализованная схема изменения состояний документов „заказ-наряд»
Состояния документа „заказ-наряд» распределены по трем группам состояний — „Приемка», „Ремонт» и „Склад и логистика». Собственно состояния, которые в каждой из групп может принимать документ, обозначены прямоугольниками со скругленными углами.
На выносках приведены документы-поводы для смены состояний заказ-наряда, через запятую указаны условия, если они имеются. Например, если на выноске стоит „Калькуляция, согласовано», то при проведении документа-повода „Калькуляция», имеющего статус „Согласована», документ-объект „Заказ-наряд» получит новое состояние. Видно, что логистам и приемке статус калькуляции важен, а мастеру — нет (его дело— заказать). Условие может относиться и к реквизитам документа-объекта, то есть, в данном случае, заказ-наряда. Так, при проведении документа-повода „Отказ от работ» проверяется тип работы, указанный в документе-объекте, то есть заказ-наряде. Для платных работ устанавливается состояние „Выдавать по оплате» (на случай, если проведенная диагностика должна быть оплачена клиентом), а для гарантийных — „Можно выдавать».
Выноски с цифрами отмечают состояния, которые подлежат обработке сотрудником — то есть как раз те папки, которые сотрудники должны „опустошать». Цифры показывают последовательность работы бизнес-конвейера. Видно, что для каждой группы сотрудников обработке подлежат те документы, к которым они способны применить свои возможности. Видно и то, что никакой заказ-наряд не может оказаться в состоянии, для которого не назначены ответственные сотрудники. Например, для того чтобы заказ-наряд покинул закладку „Проведена диагностика», мастер должен заказать запчасти либо завершить работу без применения запчастей.
Прямоугольники стреловидной формы — это процессы, в которых задействованы внешние по отношению к конфигурации (и сервисному центру) действия, события и документы. К примеру, процесс проверки гарантийности заключается в том, что сотрудник направляет запрос установленной формы производителю и дожидается ответа. По результатам проверки либо создается „Отказ от работ», либо заказ-наряд получает статус „Новый», причем эта процедура выполняется вручную.
Действия в шестиугольниках производятся до ввода документа „заказ-наряд» в процессе общения с клиентом и не документируются в системе.
Результаты
Задание выполнено, идея себя оправдала. Сотруднику не приходится задумываться, чем заняться— работа „приезжает» к нему сама. Причем, до тех пор, пока он не выполнит ее правильно, она не уедет по конвейеру дальше. Исключается необходимость выбора документа, подлежащего обработке, равно как и повторная обработка. Выбор времени исполнения легко контролируется самим сотрудником, а результат — руководством СЦ. Бизнес-конвейер обеспечивает и взаимодействие служб — автоматическим переносом задач из одной зоны ответственности в другую. Решение достигнуто без доработки базового программного обеспечения, конфигурация с поддержки не снималась, программировались только шаблоны-условия.
Примечание. Реальные процессы в СЦ несколько сложнее приведенных в статье. Несущественные для описания детали были намеренно опущены.
| |
