Saldo.ru

Публикации

28 сентября 2024, Суббота
Мастер-СальдоSaldo.ru: Бухгалтерский сервер Вход для своих
Стань своим на Saldo.ru
Забыли пароль?

Вы здесь: Saldo.ru / Бухгалтерские новости / Публикации

Публикации

Просим вас ставить ваши оценки опубликованным материалам


Версия для печати 
Шрифт:
И.ЯКОБСОН, к.т.н.,главный эксперт компании "Компас"
Материал журнала "Бухгалтер и компьютер"

ИТ в управлении качеством. Потоки документов и потоки работ в ERP-системе "КОМПАС"

В условиях обострения рыночной конкуренции на отечественных предприятиях всё большее значение придаётся организации системы менеджмента качества. Косвенно об этом свидетельствует тот факт, что количество запросов с этим словосочетанием ("система менеджмента качества") в популярной российской поисковой системе "Яндекс" неуклонно растёт и на сегодня составляет около 7 тыс. запросов в месяц. Сейчас нелегко будет найти промышленное (да и не только промышленное) предприятие, в штатном расписании которого отсутствовала бы такая должность, как "директор по качеству" или "заместитель генерального директора по качеству". Иначе говоря, важность проблемы такова, что её решение вынесено на уровень высшего менеджмента компании.
Сходные должности вводились на многих заводах уже давно. Но, во-первых, это, как правило, был уровень не директората, а в лучшем случае начальника подразделения. А во-вторых, основной акцент делался на организацию службы контроля качества продукции, разработку и (или) закупку оборудования для проверки соответствия её технических характеристик заданным значениям. В XXI веке этого мало!
Впрочем, я, наверно, слегка преувеличил интерес к системе менеджмента качества как таковой. Из бесед с генеральными директорами предприятий становится ясно, что большинство из них волнует только возможность сертификации предприятия по престижным стандартам, в первую очередь по ISO 9001:2000. Ещё бы! Ведь получение такого свидетельства позволяет повысить инвестиционную привлекательность предприятия, особенно для западного капитала.
Не секрет, что в нашей стране есть способы получить любой сертификат и без реального изменения производственных и управленческих процессов. Как говорится, существует "цена вопроса". И многие руководители охотно идут по этому пути просто потому, что он и легче, и дешевле. А зря! Ведь реальное построение системы менеджмента качества может действительно улучшить ситуацию на предприятии, повысить эффективность его работы, а следовательно, и конкурентоспособность.

Главное . стандарт
Чем же способны помочь в организации системы менеджмента качества информационные технологии? В своё время, когда я только начинал заниматься данными вопросами, желая развивать в этом направлении разрабатываемую нашей компанией ERP-систему "КОМПАС", я спросил у одного из первых в России дипломированных специалистов по управлению качеством кандидата технических наук Сергея Владимировича Башкатова, внедрение какого функционала поможет предприятию сертифицироваться по стандарту ISO 9001:2000 (как видите, я тогда тоже ставил вопрос неправильно). И получил совершенно неожиданный ответ: любого.
Потом, в процессе длительной лекции, включавшей в себя уже упомянутые выше разъяснения на тему, что "не в сертификате счастье", г-н Башкатов раскрыл логическую цепочку, приведшую его к столь краткому выводу. Вкратце его аргументы сводились к тому, что любая программа . это формализованная запись неких действий. В случае управленческого ПО . действий управленческого персонала. Получается, что внедрение любого управленческого ПО требует предварительной формализации хотя бы части бизнес-процессов. А тотальная их формализация, выработка стандартов предприятия, неукоснительное исполнение которых приводит к достижению оптимального результата, и есть необходимое (хотя и недостаточное) условие создания системы менеджмента качества.
Из дальнейших рассуждений специалиста по качеству следовало, что хотя, как он уже сказал, любое ПО . благо для реализации этих целей, но среди прочих равных функциональность, позволяющая автоматизировать описание и контроль правильности выполнения стандартных бизнес-процессов, оказывается (совсем по Оруэллу) "равнее прочих".
Чтобы разобраться, что должно "уметь" такое программное обеспечение, приведём пример стандартизации процесса отгрузки товаров по заявке клиента в торговой организации. Предусмотрена следующая последовательность действий.
1. Выявление потребности клиента.
2. Оформление заявки клиента.
3. Проверка наличия товара и, если необходимо, запуск процедуры пополнения товарных запасов.
4. Комплектация заявки.
5. Согласование условий отгрузки и доставки.
6. Формирование необходимых сопроводительных документов.
7. Исполнение заявки.
8. Контроль удовлетворённости клиента.
Надо заметить, что современные специалисты по управлению качеством в большинстве своём являются адептами клиент-ориентированных технологий, предполагающих минимизацию конфликтов и как следствие повышение лояльности клиента (в результате многие из них одновременно отвечают за внедрение CRM-систем). Поэтому особое значение они придают стандартизации выявления потребности. Всё тот же С. В. Башкатов приводит очень простой и наглядный пример.
Когда покупатель приходит в магазин электроприборов, то чаще всего "выдаёт продавцу" запрос вроде "мне нужна лампочка". В лучшем случае он сообщит, что ему нужна лампочка мощностью в 100 Вт. Гораздо реже он уточнит, какой стандарт патрона ему необходим. И уж совсем редко можно услышать, нужна ли матовая лампочка или прозрачная, круглая или свечеобразная. Продавец, как правило, не углубляется в проблемы клиента и даёт ему самый популярный товар. Клиент приходит домой, выясняет, что купил совсем не то, что ему нужно, но винит в этом, конечно же, не себя и даже не конкретного продавца, а магазин в целом. Иными словами, лояльность клиента по отношению к компании сразу оказывается под вопросом.
Чтобы избежать таких конфликтов, специалисты по менеджменту качества предлагают разбивать этап определения потребностей клиента на несколько подэтапов, связанных с выявлением той или иной характеристики товара. Выполнение каждого такого подэтапа условно, оно зависит от результатов выполнения предыдущих подэтапов. Это значит, что алгоритм реализации бизнес-процесса носит не линейный, а древовидный характер. Средства автоматизированного описания стандартизованных бизнес-процессов должны давать возможность такого ветвления. Более того, в общем случае граф бизнес-процесса может включать в себя циклические подграфы. Для приведённого примера: если не удалось успешно завершить этап комплектации, то следует осуществить возврат к этапу 3 предложенной выше последовательности.
Иногда вместо кропотливого разбиения этапа выявления потребностей можно применить средства "жёсткого контроля" за полнотой введённой информации. В этом случае автоматизированная система просто не должна разрешать переход к следующему этапу бизнес-процесса до тех пор, пока не будут заполнены все необходимые поля.
Ещё один этап, которому сторонники клиент-ориентированных технологий придают особое значение, - это контроль удовлетворённости клиента, обеспечивающий обратную связь и позволяющий оценить уровень услуг, предоставляемых каждым сотрудником компании. Впрочем, специалисты по менеджменту качества идут ещё дальше и говорят о необходимости наличия средств мониторинга прохождения всех бизнес-процессов со стороны руководства.
Важным элементом управления качества является стандартизация всех возможных значений и характеристик, вводимых во время реализации любого бизнес-процесса. Поэтому автоматизированная система менеджмента качества должна давать возможности пополнения базы данных новыми справочными таблицами, подключения этих справочников к произвольным информационным полям и запрета на ввод любых значений, не предусмотренных в справочнике.
Очень хорошо, если ПО предусматривает средства графического описания стандартизованных бизнес-процессов, которые позволяют вводить их в виде блок-схем, UML-диаграмм и т. п. Но в принципе вполне достаточно и удобного языка описания в табличной или алгоритмической форме.

На реальном примере
Практически все современные ERP-системы предоставляют пользователям функции автоматизации управления бизнес-процессами, позволяющие описывать стандарты предприятия и отслеживать их выполнение. Не является исключением и ERP-система "КОМПАС", все "проблемно-ориентированные" подсистемы которой пронизывает инструментальная подсистема "Маршрутизация", имеющая в своём составе функции DocFlow (управление потоками документов) и WorkFlow (управление потоками работ). Эту подсистему я и хочу рассмотреть в качестве примера.
DocFlow является частным случаем WorkFlow, связанным с описанием процедуры прохождения документа. В процессе прохождения документ постепенно меняет свой статус от уровня "черновик" до "подписан". Это важная часть автоматизации управленческих бизнес-процессов, так как очень многие из них связаны с созданием и прохождением документов.
В случае DocFlow термин "бизнес-процесс" можно заменить на "маршрут прохождения документа", а "типовой бизнес-процесс" - на "шаблон маршрута".
Подсистема маршрутизации документов в режиме DocFlow позволяет:
- занести шаблон в справочник шаблонов маршрутов документов;
- описать шаблон маршрута документа, в том числе разветвлённый и циклический;
- скопировать шаблон маршрута для дальнейшей корректировки;
- откорректировать шаблон маршрута;
- приписать маршрут к документу;
- переопределить маршрут документу;
- отключить маршрут от документа;
- активизировать маршрут документа;
- послать сообщение (уведомление) исполнителю о том, что документ находится на таком этапе маршрута, который требует действий исполнителя (т. е. напомнить исполнителю, что нужно работать с документом). Такое сообщение можно многократно дублировать в ходе контроля выполнения маршрутом документа. Сообщение может посылаться как по электронной почте, так и через специализированную "напоминалку", окно которой автоматически всплывает на компьютере пользователя, зарегистрировавшегося под нужным логином, при достижении заданного времени напоминания;
- разграничить доступ к операциям по корректировке приписанного к документу маршрута;
- использовать для документа "жёсткий" (описанный шаблоном) и "гибкий" (формирующийся в процессе работы над документом) маршруты. Это необходимо потому, что стопроцентная стандартизация не всегда возможна, в некоторых случаях исполнитель должен иметь "зазор";
- установить длительность этапа не только в целых днях, но и в часах в течение дня;
- задать дельту в днях даты начала нового этапа от даты завершения предыдущего этапа;
- рассчитать базовый маршрут исходя из задания желаемой даты и времени выполнения любого этапа. Рассчитывается время начала каждого этапа. Этот аппарат может использоваться в целях планирования двояким образом: рассчитывать предполагаемую дату и время завершения создания документа в зависимости от времени начала работы и, наоборот, задать предполагаемое время завершения и определить время, когда работы следует начать;
- проконтролировать, на каком этапе выполнения находится в данный момент любой документ, выявить просроченные этапы DocFlow.
В системе имеется справочник типов маршрутов, который позволяет привязать каждый шаблон к тому или иному типу документа (рядовой пользователь ограничен этими привязками). Если к одному типу привязано несколько маршрутов, то можно "указать умолчание". Все маршруты авторизованы.
Можно выделить следующую основную последовательность использования программы.
Описывается перечень этапов в каждом стандартном маршруте. При описании каждому этапу ставится в соответствие перечень переходов на другие этапы. В зависимости от того, какой статус приобретает документ по окончании этапа, переход может осуществляться в разные узлы маршрута, в том числе и на те, которые уже проходились (упомянутый выше циклический подграф).
В момент создания документа к нему автоматически приписывается типовой маршрут, который далее и "живёт" вместе с ним. Система может провести расчёт плановых сроков выполнения каждого из этапов, если задать срок выполнения базового.
В процессе обработки документа ответственный исполнитель этапа меняет статус его выполнения. В зависимости от проставленного статуса осуществляется переход к следующему (а может, и возврат к предыдущему) этапу с одновременной отсылкой уведомления его ответственному исполнителю.
Как мы уже говорили ранее, необходимым условием построения системы менеджмента качества является возможность постоянного мониторинга состояния бизнес-процесса. В применении к процессу подготовки документа руководитель может осуществлять контроль по полю "состояние этапа", которое присутствует в описании выполняемого маршрута. Ещё одним средством контроля является возможность видеть, на каком этапе маршрута находится тот или иной документ и кто является исполнителем этапа.
WorkFlow является обобщением DocFlow, ведь не все бизнес-процессы связаны с выпуском документов. Кроме того, зачастую требуется не просто менять статус документа или этапа маршрута, а генерировать какие-то записи в произвольных базах данных, контролировать выполнение определённых условий и т. д.
Инструмент "Маршрутизация" позволяет описать бизнес-процесс, который делится на выполняемые этапы, с описанием сроков выполнения, ответственных исполнителей, автоматически получаемых результатов (например, появление документа в реестре, появление специальной отметки в существующем документе, оповещение исполнителя, напоминание сроков исполнения и т. п.) после выполнения этапа.
Подсистема позволяет также провести контроль условий, при которых этап маршрута считается завершённым. Условия могут задаваться произвольные.
Функции WorkFlow реализованы посредством подключения заранее написанной в "Мастере бизнес-процедур" процедуры к этапу маршрута, описывающего общий бизнес-процесс.
Рассмотрим пример стандартизации приёма на работу. Бизнес-процесс предусматривает заключение трудового договора с предварительной проверкой комплектности необходимых документов. В случае отсутствия документов маршрут блокируется на этапе 2 "проверка комплектности документов", для чего в экранной форме предусмотрен перечень других документов, необходимых для его утверждения. Далее осуществляется проверка необходимых сопутствующих договоров, в соответствии с должностью. В случае отсутствия таких документов маршрут блокируется на этапе 7.
После этого осуществляется проверка оформления ПФ и ФОМС и заполнение соответствующих полей в личной карточке. Если поля не заполнены, программа предлагает формировать анкету.
Нетрудно видеть, что аналогичным образом может контролироваться и выяснение всей необходимой информации о заказываемом клиентом товаре в примере, который приводился в начале статьи. Это ещё раз доказывает, что описываемый аппарат способен удовлетворить основные требования специалистов по менеджменту качества.
Последним этапом автоматически формируется приказ о приёме на работу, который тут же появляется в реестре приказов. К сгенерированному приказу автоматически прикрепляется маршрут нового бизнес-процесса . оформления приказа о приёме на работу и передачи трудового договора на обслуживание в бухгалтерию. Всё, как в реальной жизни, когда завершённый бизнес-процесс порождает новый.

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


Голосов: 0 Средний бал: 0
Оцените статью: