Как потерять сотни тысяч и три года на внедрении СМК и причём тут база знаний

В список процессов вошли самые популярные и полезные:

1. отыгрывание закупки на тендерной площадке;
2. подготовка персонала;
3. плановые ремонты оборудования;
4. отработка заявок и звонков пользователей;
5. и многие другие.

Таким образом мы работали около полугода. За это время мы подготовили необходимые документы к сертификационной процедуре. Описание организационных и производственных процессов, проведение первого аудита дало нам возможность сертифицировать СМК в той же организации, которая занималась внедрением.

Получили сертификат, опубликовали новость на сайте, отпраздновали успех. А потом сели и задумались: достигли ли мы тех целей внедрения СМК, что ставили? Оказалось — нет. И это целиком моя личная ответственность — решил, что в СМК нет ничего сложного и доверился опытным людям, которые взяли за свою работу не слишком дорого. Убедил руководство, что так будет лучше. А надо было искать очень опытных людей, пусть и очень дорого — но и результат не был бы половинчатым.

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

Следующий цикл. Работа над ошибками — PDC

В ходе внедрения СМК с местным интегратором мы прошли две первых стадии процесса Деминга — планирование и действие. А потом самостоятельно провели оценку. Пришла пора внести коррективы и запустить следующий цикл.

Вот какие выводы мы сделали из первой итерации нашей деятельности.

Во-первых, лидерство, один из постулатов ИСО 9001:2015, в процессе внедрения СМК было лишь продекларировано, но на самом деле всем процессом занимались ответственный за качество и куратор от интегратора. Владельцы процессов не до конца осознали важность мероприятия и часто давали информацию и участвовали в процессе чисто формально.

Во-вторых, мы даже не пытались оптимизировать бизнес-процессы и проекты. Просто описали их так, как они были организованы на момент внедрения СМК. Работы по улучшению, которая должна была проводиться, не было, хотя для этого были все возможности.

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

В-четвёртых, мы напрасно сэкономили на интеграторе. Надо было пользоваться услугами московской компании, в которую ушёл один из специалистов российского филиала DNV GL, очень компетентный эксперт Станислав Кудрявцев — потом мы с техническим директором учились на его двухдневном курсе и поняли гигантскую разницу в уровнях специалистов. Достаточно того факта, что он сам принимал участие в разработке ISO 9001:2015. За два дня Станислав дал больше пользы, чем местный интегратор за почти год. Кстати, эта компания не пережила очередной собственной аттестации.

В-пятых, мы воспользовались не самым лучшим инструментарием для организации знаний. Гуглдоки — классная и гибкая штука, с их помощью можно сделать практически всё. Вот только организовывать это «практически всё» приходится вручную, собирать ссылки на отдельные документы вручную в синтетические «оглавления». И думать — как бы случайно не переименовать документ — создаём же копированием, чтобы потом отдельно не настраивать стили, доступы и прочее.

Действуем — Act!

К описанию бизнес-процессов приступили с нового года. И с нового года же решили, что собирать знания по СМК логичнее в новом инструменте — базе знаний. О том, как мы выбирали платформу, я писал в статье Системы work management: выбор решения для команды.

Задействуя «взрослую» базу знаний, мы решаем несколько задач:

1. упорядочиваем структуру документации;
2. в перспективе прописываем порядок утверждения новых документов средствами платформы БЗ;
3. готовим почву для создания обучающих занятий на платформе по управлению знаниями, например, по тем же процессам — чем на пальцах рассказывать сотрудникам о том, как ему работать, назначаем ему курс с последующим тестированием;
4. собираем знания, которые хранятся в головах опытных сотрудников и делаем их достоянием группы компаний;
5. планируем и отслеживаем задачи и время их выполнения, в том числе по наполнению БЗ и описанию БП;
6. и ещё много всяких ништяков.

В статье я писал, что в финал вышли две системы: Teamly и Platrum. Покрутив обе, посмотрев как на интерфейс, так и на раздел с тарифами, выбрали первую. Что сыграло:

1. тарифная политика — нам удобно завести минимальное количество редакторов (5 человек), у остальных сотрудников будет гостевой доступ;
2. возможность поработать бесплатно на этапе первоначального наполнения БЗ.

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

Описание бизнес-процесса

Чисто технически процессы мы отрисовываем в draw.io, а в Teamly ведём реестр (пока это реестр сессий рабочей группы), фиксируем выводы и задачи по каждому процессу. Пока не начали, но запланировали текстовое описание каждого шага БП и определение параметров эффективности с тем, чтобы получить нормальную карту, которая станет составляющей системы менеджмента качества.

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

В ходе составления схем БП мы сразу находим петли и кружные пути и занимаемся оптимизацией. Приведу наш пошаговый алгоритм описания бизнес-процесса в базе знаний Teamly.

1. Снять конфликт определений. Все участники рабочей группы должны однозначно понимать значение всех сущностей, участвующих в описываемом процессе.
2. Договориться о том, что является результатом процесса. Например, по БП «Служебная записка» долго спорили о том, будет ли результатом исполнение изложенной в записке просьбы или только виза типа «Удовлетворить», «Передать в работу», «Оставить без удовлетворения». Кстати, договорились на визе — иначе бы процесс получился очень ветвистым и с непонятным результатом.
3. Определить участников процесса и его владельца.
4. Прописать ход процесса.
5. Договориться о показателях эффективности процесса и их конкретных значениях. Например, у БП «Служебная записка» показатель эффективности — это срок рассмотрения от получения до визы.

Всё это даёт возможность не просто нарисовать схему — вот документ от офис-менеджера пошёл к адресату. А и определить показатели, которые будет контролировать аудиторская группа в ходе проверок процессов в рамках СМК.

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

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

Для статей в разделах БЗ, а не умных таблицах, можно запускать механизм согласования. На бесплатном тарифе он недоступен — вот сделаем первоначальное наполнение, заплатим за тариф, тогда и задействуем. И, возможно, тогда же понадобятся чаты статей — есть и такой функционал. Удобно, когда всё по статье лежит внутри неё.

Оптимистичные выводы

Итак, основные мысли, которые мы для себя сформулировали:

1. доверяясь эксперту, нужно проверить его компетенции, а не только цену; не всегда дешевле = лучше, но и не всегда дороже = лучше;
2. встречи нужно начинать с определений и предполагаемых результатов — тогда и обсуждения будут продуктивнее;
3. нужно фиксировать достигнутые договоренности и планы дальнейших действий прямо на встрече, потом забывается;
4. стоит использовать подходящие задаче инструменты и не пытаться запихать всё в Google Sheets.

С таким подходом мы надеемся за год описать и оптимизировать все основные бизнес-процессы группы компаний, параллельно создавая базу знаний для их сохранения и быстрого онбординга новичков.

Сейчас мы вооружены не только знаниями, но и опытом. У нас уже есть

Суждено ли планам сбыться? Stay tuned )