Вступление
Эта статья ориентирована на тех, у кого есть SharePoint и кто не знает, что с ним делать. :)
Много везде говорят о бизнес-процессе, но мало кто подразумевает под этим действительно процессный подход, скорее представляют себе некоторый черный ящик, где, в лучшем случае, есть вход и выход, иногда даже структурированный – определено, что имеем на входе и на выходе. Фактически, если в ящике за процесс отвечают более двух человек — легкий хаос вам обеспечен, а с ростом количества вовлеченных обеспечен и экспоненциальный рост энтропии. :)
Процесс в управлении организацией — это совокупность действий, повторяемых во времени, с конкретным началом и концом, целью которых является создание ценности для внешних и внутренних клиентов. По сути – преобразование ресурсов на входе в продукт на выходе, продукт может быть любым – как материальным, так и неосязаемым знанием. Преобразование в ящике может быть предельно простым, не требующим декомпозиции, а может быть очень сложным, вовлекающим в работу много сотрудников и времени, имеющим множество условий и зависимостей. Вопрос уровня декомпозиции процесса лежит в плоскости рациональности, целесообразности и здравого смысла, мне нравится методологический принцип «Бритва Оккама», который гласит, что «Не следует привлекать новые сущности без крайней на то необходимости», там, где можно обойтись без формализации действия — формализовывать действие не стоит. :)
Суть дела
Легкое погружение в теорию закончилось, вернемся к нашему кейсу. Есть у нас производственное предприятие, которое, как и все прочие, помимо основного продукта, производит брак, куда без него. И есть на том предприятии Отдел качества (ОК), цель существования которого — брак фиксировать, способствовать устранению, всячески предупреждать и пресекать. Да, что там Отдел качества, целая Система менеджмента качества (СМК), внедрена на предприятии, соответствующая и сертифицированная по стандартам ISO 9001. Казалось бы, ОК есть, СМК есть, на бумаге все процессы прописаны, все соответствует международному уровню, работай — не хочу!
Но! Акт о браке или акт входного контроля может ходить месяц-другой с учетом выходных и праздников между подразделениями и сотрудниками предприятия. Как так? Акт входного контроля, попадая к юрисконсульту, для составления претензии поставщику уже опоздал, вышли все сроки по договору поставки для оформления возврата. А сколько таких случаев? А сколько у нас актов в работе? А на каком они этапе? А на каком этапе они застревают больше всего? Какое подразделение генерирует больше брака? А кто виновник? А кто устраняет чаще? У какого поставщика хуже качество? А сколько претензий отправлено поставщикам и без ответа? Какие мы несем затраты? И много других вопросов. Будем анализировать бумажные журналы и папки с актами, объяснительными, калькуляциями затрат?
Что делать?
— А давайте вместо бумажных журналов сделаем акты электронными, создадим последовательный процесс работы над актом?
— Давайте!
— У нас есть SharePoint, он ведь подойдет?
— Конечно!
— Весь процесс у нас уже описан, надо только перенести.
— Запросто!
Как видите, решение нашлось быстро и работа закипела.
Документация!
Наученный горьким опытом, скажу одну, казалось бы, очевидную вещь, о которой даже спорить не буду ни с кем, просто скажу как факт – всегда начинайте проект автоматизации с разработки блок-схемы процесса, попутно делайте подробный документ-описание схемы и никогда не начинайте разработку, не имея этих согласованных документов!
- Во-первых, это поможет вам в декомпозиции процесса, т.е. в самой разработке, визуальное представление позволит лучше систематизировать действия, учесть максимум условий и зависимостей.
- Во-вторых, эти два документа, обязаны лечь в основу технического задания, поэтому необходимо вовлечь в работу над ними владельца процесса и спонсора, а лучше всех задействованных в процессе лиц. Обязательно соберите совещание, когда посчитаете, что все, готов проект – пора переносить с бумаги в шайтан-машину. Обсудите все стадии и состояния процесса, все возможные ветвления, скорее всего, вы учли не все. Лучше учесть на этапе проектирования, чтобы не пришлось менять фундамент готового дома.
Можете мне не верить и работать без схемы и подробного описания, бесконечно меняя процесс под новые гениальные идеи участников.
Реинжиниринг!
Еще один момент – не стоит полностью полагаться на компетенции владельца процесса и ожидать, что он станет вашим главным консультантом. Главным вашим консультантом должен стать ваш здравый смысл и только. Все действия процесса, все зависимости и условия стоит подвергать сомнению – задавать вопросы «Зачем?», «Чем это обусловлено?», «Можем ли мы от этого отказаться?». Чем проще получится ваш процесс – тем больше у него шансов запуститься и остаться работоспособным в организационном плане. Также вероятно, что процессу придется трансформироваться с учетом технических особенностей выбранной платформы автоматизации. Ваша задача оптимизировать процесс, сделать его максимально человеконезависимым, прозрачным, управляемым и ограниченным во времени для достижения максимальной эффективности. Это и называется реинжиниринг. «Бритва Оккама» вам в помощь!
Поехали!
Изучив процесс управления актами о браке, описанный в СМК и изучив процесс физический, стало понятно, что все не так просто.
Процесс описан весьма скудно и общими словами, а физически он оказался очень сложен – на каждом шагу новое условие «ЕСЛИ» и каждый новый шаг тянет за собой новые зависимости.
Перекладывая на схему два физических процесса – акт о браке и акт входного контроля, выяснилось, что они почти идентичны – используют одинаковые данные, одинаковые действия, а отличаются немного выходным результатом. А значит, не стоит плодить лишних сущностей – объединяем!
Таких моментов было немало, попутно обо всех изменениях мы информировали всех вовлеченных в процесс участников, и, наверное, после десятого варианта процесса, мы с владельцем и спонсором решили, что все готово, вариант конечен, можно доделывать и запускать.
Решили собрать совещание, пригласив всех вовлеченных, чтобы рассказать и продемонстрировать, пройдясь по всем стадиям, как новый процесс будет работать, где и чья ответственность. И тут же выяснили с юрисконсультом, что очень желательно стадию обработки претензии к поставщику по акту входного контроля контролировать и, в случае отказа или частичного отказа, в случае истечения выделенного срока – вовлекать в работу юрисконсульта и вовлекать только в этом случае, потому что в остальных случаях, обработка претензии – абсолютно рядовой процесс. И тут же выяснили, что стадия обработки претензии после переговоров с поставщиком может изменить решение по акту с возврата поставщику на, допустим, коррекцию своими силами с частичным возмещением затрат поставщиком. Разные мелочи также были учтены, навроде, требований и пожеланий бухгалтерии по печатной форме акта и живым подписям, пожеланий главного инженера по автоматическому созданию претензии.
То ли одиннадцатая, то ли двенадцатая версия оказалась завершающей и еще одно совещание ее полностью одобрило. Кстати, без схемы ваши совещания были бы скучными – собравшиеся вас просто не поняли бы, покивали бы и согласились, мол «Давайте, делайте, а там видно будет».
Скучная техническая часть
Расскажу немного о том, как процесс реализован технически.
В узле SharePoint созданы настраиваемые списки, которые используются в качестве журналов или справочников. Связи между ними обеспечены путем использования столбцов подстановки и рабочих процессов.
Посредством SharePoint Designer доработаны стандартные формы и созданы новые, например, аккумуляция связных данных в форме просмотра акта о браке, печатная форма акта или печатная форма претензии поставщику.
Кастомизация отображения форм – вопрос обширный и решений имеет такое же множество. К примеру, можно просто скрывать определенные поля в разных формах параметрами ShowInDisplayForm, ShowInEditForm, ShowInNewForm. Приложений для настройки параметров много – например, SharePoint Manager. Для удобства какие-то поля можно отобразить в форме редактирования, но присвоить элементу атрибут Disabled посредством простого Javascript. Вообще, Javascript всегда спасает, например, нужно создать комментарий, находясь в карточке просмотра договора, или исполнение по служебной записке, нажимаете кнопку «Создать», в которой передаете ID текущего элемента в форму создания нового элемента. Скриптом забираете ID и выбираете нужное значение в элементе Input.
Также, можно создать с нуля любые формы в SharePoint Designer, а кому-то может понравиться InfoPath.
В 2007 и 2010 версиях можно использовать расширение Office Toolbox, где просто и удобно все настраивается галочками, в том числе поле можно отобразить в форме редактирования, но Read Only.
Рабочие процессы (Workflow) созданы посредством SharePoint Designer. Рабочие процессы обеспечивают как сам бизнес-процесс, так и согласованность данных в некоторых случаях.
В 2007 версии SharePoint иногда помогают Useful Sharepoint Designer Custom Workflow Activities, например, когда после редактирования нужно оставить права только на чтение для элемента. В 2010-2013 версиях таких проблем нет – все есть из коробки, вообще, в свежих версиях наличие шага олицетворения несколько меняет подход к проектированию логики процессов – значительно упрощая.
Ограничение стадий по времени организовано путем создания дополнительного рабочего процесса с таймером, который ждет отведенное время и по истечении его проверяет заполнение необходимых полей. Если все плохо, устанавливает «Отклонение равно Да» и отправляет уведомления всем заинтересованным лицам. Для лучшей визуализации можно добавить поле типа гиперссылка в которое записывать ссылки на стандартные картинки-индикаторы, например, созданное, требующее реакции – желтый значок, своевременно заполненный элемент – зеленый, и отклонение – соответственно, красный.
Процесс готов!
Вот так выглядит наша документация, которая приказом введена в действие:
Схема процесса работы с актами о браке
Регламент работы с актами о браке
Регламент работы с актами о браке
Термины и определения
Контролер – лицо, ответственное за проверку качества принимаемой у производства и поставщиков готовой продукции, материалов, сырья (контролер или руководитель отдела качества).
Экономист – лицо, ответственное за планирование и фактическую калькуляцию материальных и трудовых затрат (экономист-нормировщик или руководитель финансово-экономического отдела).
Техотдел – лицо, ответственное за конструкторскую и технологическую подготовку производства (Главный конструктор, Главный технолог или заместитель).
Бухгалтер – лицо, ответственное за учет производственных затрат и расчет заработной платы (бухгалтер по производству, себестоимости, зарплате или Главный бухгалтер).
Главный инженер – лицо, имеющее право подписи документов, при его отсутствии – лицо исполняющее обязанности главного инженера.
Список – электронная таблица (журнал), имеющая столбцы, где каждая строка (запись) представляет собой отдельный элемент.
Элемент списка – строка списка, имеющая уникальный идентификатор, которая может содержать вложения документов, иметь разграниченные права доступа пользователей, запускать рабочие процессы.
Рабочий процесс (РП) – программа, определяющая логику действий и выполняемая автоматически при наступлении определенных событий, таких как, создание или изменение элемента/документа в списке, наступление заданной даты.
Общее описание
Для организации процесса управления электронными актами о браке используются списки узла «Отдел качества» портала предприятия, находящегося по адресу portal.domain.ru/SiteDirectory/quality
Списки можно представить как бумажные журналы регистрации, где есть строки и поля для заполнения, каждая строка – это уникальная запись, имеющая атрибуты. Отличие заключается в том, что запись в электронном списке может иметь вложения, запускать рабочие процессы для автоматизации действий, например, отправить уведомление, изменить любое значение, записи в списке можно динамически сортировать, группировать, калькулировать любые значения атрибутов и подводить итоги.
Используя указанные списки, а также автоматизированную логику действий, настроенную посредством применения программируемых рабочих процессов, созданы процессы управления электронными актами о браке (несоответствии).
Процессы учета и обработки актов о браке
1. Создание Акта контролером
Для регистрации актов создан список «Акты о браке» (https://portal.domain.ru/SiteDirectory/quality/Lists/List). Фиксация актов о браке осуществляется контролером отдела качества в соответствии с правилами, принятыми в организации.
При создании записи в «Актах о браке» заполняются следующие поля:
Входной контроль – выбор Да/Нет (указывается Да в случае если регистрируется несоответствие входного контроля материалов и готовой продукции от внешнего поставщика)
Обнаружено – выбор цеха, где обнаружено несоответствие (обязательное)
Возникло – выбор цеха, где возникло несоответствие (обязательное)
Контролер – выбор ФИО ответственного контролера отдела качества (обязательное)
Продукция – наименование несоответствующей продукции (обязательное)
Количество – числовое количество несоответствующей продукции (обязательное)
Несоответствие – подробное описание несоответствия продукции (обязательное)
Маршрутный лист/Операция/Рабочий – перечисление производственных характеристик (обязательное)
Примечание – необязательное текстовое поле
Запись может также иметь вложения файлов (фотографии, чертежи, документы).
При редактировании записи доступны те же поля, что и при создании.
2. Принятие решения ОКК
После регистрации акта о браке автоматически создается элемент в списке «Решения по браку» (https://portal.domain.ru/SiteDirectory/quality/Lists/List6) и отправляется уведомление в отдел качества.
Руководитель отдела качества или ответственный инженер должен принять решение.
При изменении записи в списке «Решения по браку» заполняются следующие поля:
Решение – выбор значений из справочника «Решения» (https://portal.domain.ru/SiteDirectory/quality/Lists/List7) Возврат поставщику/Коррекция/Отступление/Утилизация (обязательное)
Устраняющий цех — выбор значений из справочника «Подразделения» (https://portal.domain.ru/SiteDirectory/quality/Lists/List1) (обязательное)
Коррекция – описание мер для устранения несоответствия (обязательное)
При просмотре элемента доступны следующие поля:
Принял решение – учетная запись сотрудника отдела качества, принявшего решение по несоответствию, поле заполняется автоматически после сохранения элемента
Срок – в течение 4 рабочих часов с момента получения уведомления.
3. Определение корректирующих действий
После регистрации акта о браке автоматически создается элемент в списке «Корректирующие действия» (https://portal.domain.ru/SiteDirectory/quality/Lists/List11) и отправляется уведомление руководителю подразделения, где возникло несоответствие. Статус Акта меняется на «Решение руководителя ОКК».
Руководитель подразделения должен отреагировать, заполнив обязательные поля.
При изменении записи в списке «Решения по браку» заполняются следующие поля:
Причина несоответствия – выбор значения из справочника «Несоответствия» (https://portal.domain.ru/SiteDirectory/quality/Lists/List5)
Виновник – ФИО исполнителя или наименование поставщика
Корректирующие действия – меры, принятые или планируемые для предотвращения возникновения подобных несоответствий в дальнейшем
При просмотре элемента доступны следующие поля:
Принял решение – учетная запись руководителя подразделения, где возникло несоответствие, принявшего решение по несоответствию, поле заполняется автоматически после сохранения элемента
Срок – в течение 16 рабочих часов с момента получения уведомления.
4. Согласование решения Техотделом
После принятия решения по несоответствию руководителем отдела качества автоматически создается элемент в списке «Согласование решения» (https://portal.domain.ru/SiteDirectory/quality/Lists/List9) и отправляется уведомление руководителю Техотдела. Статус Акта меняется на «Согласование Техотделом».
Руководитель Техотдела должен согласовать или отклонить, предложенное отделом качества решение.
При изменении записи в списке заполняются следующие поля:
Согласовано – выбор значения Согласовано/Отклонено (обязательное)
Комментарий – текстовое поле с пояснениями (обязательное)
Поля, доступные при просмотре записи:
Согласовал – учетная запись сотрудника Техотдела, согласовавшего или отклонившего решение по несоответствию, поле заполняется автоматически после сохранения элемента.
На стадии согласования решения возможны два сценария:
- 1. Техотдел отклонил предложенное решение.
Происходит возвращение на стадию 2 рабочего процесса, когда заново создается решение для руководителя отдела качества. Статус Акта меняется на «Решение руководителя ОКК». Предыдущее решение сохраняется для истории. - 2. Техотдел согласовал предложенное решение.
Переход к стадии 5 процесса.
Срок – в течение 4 рабочих часов с момента получения уведомления.
5. Калькуляция затрат
После согласования решения автоматически создается элемент в списке «Калькуляция» (https://portal.domain.ru/SiteDirectory/quality/Lists/List8) и отправляется уведомление экономисту-нормировщику подразделения, выбранного руководителем отдела качества в качестве устраняющего. Статус Акта меняется на «Калькуляция затрат».
Сотрудник экономического отдела должен выполнить калькуляцию затрат (материальных, трудовых, прямых и косвенных), связанных с данным несоответствием, с реализацией решения по устранению несоответствия.
Запись может также иметь вложения файлов (фотографии, чертежи, документы).
При изменении записи в списке заполняются следующие поля:
Полуфабрикаты – сумма затрат на полуфабрикаты в рублях (обязательное)
Материалы – сумма затрат на материалы в рублях (обязательное)
Зарплата – сумма затрат на заработную плату в рублях (обязательное)
Описание – текстовое поле с пояснениями (обязательное)
Завершена – логическое поле Да/Нет (Значение Да (галочка) ставится по завершению выполнения калькуляции)
Поля, доступные при просмотре записи:
Пенсионные – сумма затрат на пенсионные страховые взносы в рублях (вычисляемое поле по формуле «=ОКРУГЛ((Зарплата*0,321);2)»)
Общие – сумма общепроизводственных затрат в рублях (вычисляемое поле по формуле «=ОКРУГЛ((Зарплата*2,18);2)»)
Сумма – сумма всех затрат в рублях (вычисляемое поле по формуле «=Полуфабрикаты+Материалы+Зарплата+Пенсионные+Общие»)
Выполнил – учетная запись сотрудника экономического отдела, выполнившего калькуляцию затрат по несоответствию, поле заполняется автоматически после сохранения элемента.
Срок – в течение 8 рабочих часов с момента получения уведомления.
5.1 Проверка условий
После выполнения калькуляции происходит проверка условий и ожидание определения корректирующих действий со стадии 3 процесса.
Если определение корректирующих действий со стадии 3 процесса не выполнено, статус Акта меняется на «Определение корректирующих действий».
После выполнения определения корректирующих действий руководителем подразделения, где возникло несоответствие, возможны два сценария:
- Затраты равны нулю.
Переход к стадии 5.2 процесса. - Затраты больше нуля.
Переход к стадии 6 процесса.
5.2 Проверка условий
После проверки условий на соответствие типу акта «Входной контроль» и решения ОКК «Возврат поставщику» возможны 2 сценария:
- Входной контроль – Нет.
Переход к стадии 9 процесса. - Входной контроль – Да.
Переход к стадии 8 процесса.
6. Принятие решения Главным инженером
После выполнения калькуляции, определения корректирующих действий и если затраты больше нуля автоматически создается элемент в списке «Согласование затрат» (https://portal.domain.ru/SiteDirectory/quality/Lists/List10) и отправляется уведомление Главному инженеру. Статус Акта меняется на «Согласование Главным инженером».
Главный инженер должен принять решение куда отнести затраты, связанные с несоответствием.
При изменении записи в списке заполняются следующие поля:
Отнести затраты – выбор значения На виновника/На производство/На поставщика (обязательное)
Комментарий – текстовое поле с пояснениями (обязательное)
Поля, доступные при просмотре записи:
Принял решение – учетная запись Главного инженера, принявшего решение по отнесению затрат, связанных с несоответствием, поле заполняется автоматически после сохранения элемента.
На стадии согласования решения возможны два сценария:
- Главный инженер принял решение Отнести затраты на На производство или На виновника
Переход к стадии 7 процесса. - Главный инженер принял решение Отнести затраты на На поставщика
Переход к стадии 8 процесса.
Срок – в течение 4 рабочих часов с момента получения уведомления.
7. Закрытие Акта
После принятие решения Главным инженером по отнесение затрат на производство статус Акта меняется на «Закрыто», отправляются уведомления для Отдела качества, Экономического отдела, Бухгалтерии и Руководителю подразделения, где возникло несоответствие.
Руководитель подразделения должен распечатать Акт, подписать сам, взять подпись у Виновника, подписать у главного инженера и передать Акт в бухгалтерию.
Срок – в течение 8 рабочих часов с момента получения уведомления.
8. Создание претензии
После принятие решения Главным инженером по отнесение затрат на поставщика или при отсутствии затрат, но с решением входного контроля о возврате поставщику, статус Акта меняется на «Обработка претензии», автоматически создается запись в списке «Результаты претензии» (https://portal.smz.ru/SiteDirectory/quality/Lists/List12), формируется ссылка на форму печати претензии, отправляются уведомления для Отдела качества, Главного инженера, Экономического отдела и Руководителю подразделения, где возникло несоответствие.
Главный инженер должен распечатать Претензию, подписать, поставить печать предприятия и передать Претензию Руководителю подразделения, ответственного за данную поставку несоответствующей продукции.
Переход к стадии 10 процесса.
9. Закрытие Акта
После калькуляции затрат и определения корректирующих действий статус Акта меняется на «Закрыто», отправляются уведомления для Отдела качества, Главного инженера, Экономического отдела и Руководителю подразделения, где возникло несоответствие.
10. Обработка претензии
Руководитель подразделения, ответственного за данную поставку отправляет Претензию поставщику, проводит все необходимые мероприятия, связанные с возвратом несоответствующей продукции и по результатам работы вносит изменения в соответствующую запись в списке «Результаты претензии» (https://portal.domain.ru/SiteDirectory/quality/Lists/List12).
При изменении записи в списке заполняются следующие поля:
Претензия удовлетворена – выбор значения Да/Нет/Частично/Отмена решения (обязательное)
Комментарий – текстовое поле с пояснениями (обязательное)
Поля, доступные при просмотре записи:
Принял решение – учетная запись Руководитель подразделения, отчитавшегося по результатам обработки Претензии, поле заполняется автоматически после сохранения элемента.
На стадии обработки результатов Претензии возможны три сценария:
- Результат удовлетворения Претензии — Да
Переход к стадии 11 процесса. - Результат удовлетворения Претензии – Нет или Частично
Переход к стадии 12 процесса. - Результат удовлетворения Претензии – Отмена решения
Переход к стадии 2 процесса. Отменяются все изменения и заново создается решение для руководителя отдела качества. Статус Акта меняется на «Решение руководителя ОКК». Предыдущее решение, калькуляции и все согласования сохраняются для истории.
Срок – в течение 30 дней с момента получения уведомления.
11. Закрытие Акта
Претензия удовлетворена полностью, статус Акта меняется на «Закрыто», отправляются уведомления для Отдела качества, Главного инженера, Экономического отдела и Бухгалтерии.
12. Закрытие Акта
Претензия удовлетворена частично или не удовлетворена, статус Акта меняется на «Закрыто», отправляются уведомления для Отдела качества, Главного инженера, Экономического отдела, Бухгалтерии и Юрисконсульта.
Обещанные картинки
Главная страница узла содержит веб-части, таргетированные на разные группы пользователей. Веб-части отображают элементы, адресованные пользователю и требующие реакции
Страница просмотра акта содержит форму просмотра элемента, отображающую необходимые поля, а также веб-части, связных списков, отображающих все элементы, относящиеся к данному акту
Печатная форма акта (например, необходима в случае взыскания ущерба с виновника)
Печатная форма претензии поставщику (формируется в случае акта входного контроля и отнесения расходов на поставщика)
Резюме
Внедрение подобного процесса позволило сократить время обработки акта до 1-3 дней. Естественно, повысилась прозрачность и управляемость процесса. Процесс стал осязаемым, измеряемым и соответственно контролируемым. Как следствие, повысилась личная ответственность вовлеченных участников. Значительно сократилось количество ручного труда даже от такой простой вещи как печать претензии поставщику. При обработке претензии юрисконсульт может своевременно реагировать, сокращая потери, а руководству доступна любая отчетность по процессу в реальном времени.
Трудозатраты – 2-3 недели работы специалиста. Стоимость внедрения посчитаете сами?
У меня много есть подобных кейсов, продолжать? :)
Автор: itstrategist
