Дьявол скрыт в деталях
Для этого моими предшественниками был разработан целый регламент "Как описывать бизнес процессы". В нем все было конкретно. Рисуешь такую-то схему, делаешь к ней описание, прикладываешь печатные формы документов, инструкции по их заполнению, образец заполнения, ролевые инструкции и еще кучу других документов. В результате на один процесс получался нехилый такой пакет документов.
Скажу сразу, раньше я такого никогда не видел. Я конечно слышал, что есть PMI PMBOOK, и даже прошел соответствующий курс. Что есть 34-й и 19-й ГОСТы. Что есть технологии бережливого производства и экстремального программирования. И какие-то из рекомендаций я пытался применять на разных проектах. Но не было главного - единой методологии, которую можно было бы начать использовать.
В основном приходилось работать по образцам документов, которые раньше делали для какого-то клиента. В каждом проекте добавляется что-то новенькое. Ничего особенно не контролировалось поэтому широко применялся авторский подход разных специалистов при формировании проектных документов. Не было единой системы и методологии подготовки каждого документа. У многих ее нет и сейчас.
Например, у Вас есть шаблон формы "Отчет об экспресс-обследовании"? Есть? Отлично. А пример заполнения? Тоже есть? Замечательно. И конечно же у Вас есть инструкция по заполнению данного отчета. Просто удивительно. И последний вопрос: у Вас прописана технология подготовки данного отчета? Я в шоке. Вы скорее исключение.
Поэтому, поймите мое изумление, когда я увидел данный стандарт. Мысленно я снял шляпу перед теми, кто его составлял. Его можно было сравнить с процедурой запуска ракеты. Где все этапы были подробно прописаны и нормированы. Для новых сотрудников - просто незаменимая вещь. Делай по инструкции в нужные сроки, заполняй такие-то формы и получишь результат гарантированного качества. Точнее получишь полностью описанный бизнес-процесс.
Много позже я столкнулся с такой постановкой дела только на промышленных предприятиях. Где в технологии производства каждого изделия были прописаны необходимые операции. И то видел не на всех, а в основном тех, где работали специалисты еще старой, советской закалки. Ну да это другая история.
Вы, конечно же знаете, что при выполнении проектов требуется провести анализ автоматизируемых бизнес-процессов. Так вот, в этом направлении ИТ компании прошли совсем маленький путь. Я думаю, что это связано с тем, что команда, сформированная на проект, не обладает необходимой компетенцией. Не секрет, что выполнив проект, команда расформировывается и затем редко собирается вместе. В результате не получается использовать и, главное, накапливать компетенции и навыки. Я уж молчу про методологию.
Так вот на этом предприятии команда была постоянная и занималась одной деятельностью - выпеканием бизнес-процессов. И качество их было очень высокое. А вот как оно достигалось я сейчас и расскажу.
Итак, в процессе работы над бизнес-процессом, например процессом "Оценка качества доставки", в рабочую группу включались руководители отделов, которых данный процесс затрагивал. Далее с каждым из них проводилось интервьюирование, затем прототипирование и формализация. И готовился документ, опять таки известной формы. Далее этот документ внимательно изучали и правили. Внимание уделяли каждой детали. Какого цвета линия на схеме, как пронумерованы процессы, шрифт, логика и так далее. Далее документ подписывался членами рабочей группы. И вот, таким образом, шла работа над каждым документом.
Для меня это было в новинку. Не секрет, что на многих проектах документы формируются не самым должным образом. И принимаются и отправляются клиенту практически после первой редакции. Соответственно и ошибок в них немерено. Это, в свою очередь, компенсируется нежеланием ответственных сотрудников и клиента и ИТ-компании вникать в детали. А почему, я расскажу в другой истории.
Так вот, в результате появлялся пакет документов на бизнес-процесс. Еще раз внимательно проверялся и подписывался всеми членами рабочей группы. Я еще раз проверял, ставил свою подпись и нес такой процесс на утверждение президенту компании.
И вот тут начиналось самое интересное. Президент начинал вникать в процесс. При мне. Очень подробно. Он сравнивал шрифт со стандартом, проверял логику процессов, контролировал соответствие названия процессов в схеме, в описании, в ссылках в документах и ролевых инструкциях.
Например, в схеме процесс имеет имя: "П01 Звонок клиенту", а в описании имеет имя: "П 01 звонок клиента". Попробуйте найти ошибку. Нашли? Сколько ошибок? 1? 2? 3? Молодцы, именно три ошибки. Давайте считать.
1 ошибка: пробел между буквой "П" и цифрами "01"
2 ошибка: слово "звонок" с маленькой буквы
3 ошибка: не правильное окончание слова "клиента"
Дело тут не том, как нумеровать, хотя на это тоже был отдельный регламент, а в том, что процесс должен иметь одинаковое название везде, где на него имеется ссылка.
Собственно после того как ошибка была найдена президентом, дальнейшая проверка прекращалась. Всем кто подписал документ автоматически шел штраф 100 баксов. И весь пакет документов отправлялся на переделку. Это был единственный руководитель, который, за всю мою практику, ТАК проверял документы.
В месяц у меня стабильно 500-1000 баксов на штрафы уходило. Дело даже не в штрафах, а в том, что весь пакет документов надо было править, затем заново согласовывать и подписывать. Это было очень трудоёмко.
Это было непривычно. Я ругался, матерился (про себя конечно). И шел на второй круг. Затем на третий, четвертый и так далее. К пятому мне было абсолютно все равно, есть там ошибки или нет. Я видеть не мог эти процессы. Они мне снились. Я во сне рисовал схемы и корректировал документы.
Меня хватило на полгода. Затем были новые компании и новые проекты. И никто из руководителей после не уделял столько внимания документам. И вдруг я заметил такую особенность. Каждый раз когда я готовлю какой-нибудь документ, я автоматически проверяю его правильность. Я сразу же вижу ошибки и исправляю их. А уж про документы, которые готовили консультанты на проектах, я вообще молчу - там столько ошибок. Жаль, что я не мог их штрафовать. Поэтому ограничивался указанием на самые критичные. Особенного смысла в них вкладывать своих усилий не было, потому что завтра они уйдут на другой проект и может с ними я никогда больше работать не буду.
Источник: группа "Записки внедренца 1С" (http://www.facebook.com/groups/Zapiski/)
См. также
Специальные предложения
Всё должно быть в меру,. на высшем уровне и с вниманием к деталям - но без фанатизма. Как к это приучить себя и сотрудников? Хз... Но точно не штрафами. Ибо после штрафов самые адекватные и толковые тупо увольняются. И мы возвращаемся опять к первому тезису, что фанатизм - это деньги на ветер.
есть - напечатать документ 1 и передать сотруднику 2 в 15.00, напечатать документ 2 и передать сотруднику 4 в 16.00
а есть - подготовить комплект документов 1,2 и 4 в установленные сроки (список документов отдельно со сроками) и передать ответственным (список отдельно)
первый - уже описание тех процесса а второй регламент.
что из них проще потом править?
только там слов побольше. ;) но суть таже - менялись документы - формы и порядок. И система справок и инструкций оказалась более гибкой чем монолитная.
Но опять же коммандировка - живой пример 2 месячной давности. Сломался процесс - человек из 1 коммандировки уехал в другую сразу- без сдачи документов и процесс поплыл...
Мы все свидетели постоянно и быстро меняющейся ситуации - но продолжаем создавать нечто - на года и века.
Есть еще один момент - очень часто для того, чтобы иметь рычаг давления на ИТ-компанию, надо настаивать на включение в договор пунктов, в которых указывается какие разделы из ГОСТа нужно в проекте обязательно исполнить ИТ-компании. Это один из способов сделать так, чтобы проект шел за счет ИТ-компании.
Вернее их нарисовал другой человек и прекрасно изложил в статье
Особо стоит обратить внимание на раздел "А нужно ли вообще техническое задание? А Технический проект?"
Аргумент такой - на больших предприятиях очень много сил влияния. И внедренец, дабы не попасть в сложную ситуацию по разборке между двумя силами, должен иметь рычаг влияния. ТЗ как раз тот самый рычаг.
В маленьких компаниях с одним центром силы - можно внедрить проект за счет собственных сил. Без излишней бюрократии. Вполне допустимо использовать технологии из экстремального программирования и Agile.
По-моему менеджера который штрафовал бы консультантов за ЭТО надо увольнять, притом немедленно. Конечно в госконторах и конторах вроде газпрома люди этим занимаются, и прикиньте, им за это платят.
Притом самое интересное что этим занимаются как правило на этапе бизнес-анализа и проектирования, который предшествует этапу разработки и который нельзя распарралелить, этим просто весь проект сдвигают в ... вообщем в совсем другие сроки.
И такое придирчивое отношение к оформлению - это правильно, особенно на начальном этапе работы, чтобы приучить сотрудника к определенной системе.
Просто чем больше автоматизация, тем меньше требований к пользователям, тем меньше их квалификация и тем меньше они задумываются над своими действиями и результатами. А правильная инструкция позволяет снизить вероятность ошибок. Кроме того она же позволяет избежать потери "сакральных данных" при уходе сотрудников.
В восточных единоборствах есть правило: сначала изучается какая-нибудь техника ведения боя, но высший уровень овладения техникой является свобода от нее.
Так и в данном примере: был привит некий навык, корни которого сохранились даже тогда, когда автор отказался от полного следования технике.
Два своих подобных примера:
Пример 1. При проверке дипломных наш декан, найдя три ошибки на листе, возвращал его студенту, не читая дальше. На возражения типа: "Машинистка ошиблась", он отвечал: "Диплом получаете вы, а не машинистка".
Пример 2. У мужа при проверке курсовых работ (с кучей чертежей!) его преподаватель находил нечто не подписанное и тут же сверху писал "апельсин". Работу приходилось переделывать.
Антипример 1. Начальник (!) экономического отдела делает расчеты, которые приходится выборочно перепроверять финдиру. Иной раз финдир вынуждена делать их сама (если результат очень важен). Почему не уволят?! А другие хуже.
(52) comol, маленькая деталь в статье приведён пример ошибки, где перепутан "звонок клиента" "и звонок клиенту" Перепутано направление звонка. Это серьёзная ошибка.
"Например, у Вас есть шаблон формы "Отчет об экспресс-обследовании"? Есть? Отлично. А пример заполнения? Тоже есть? Замечательно. И конечно же у Вас есть инструкция по заполнению данного отчета. Просто удивительно. И последний вопрос: у Вас прописана технология подготовки данного отчета?"
Чем отличается
"инструкция по заполнению данного отчета" и
"технология подготовки данного отчета" ?
Вообщем описывается процесс подготовки отчета.
Простой пример. У вас новое предприятие. Вам необходимо через 5 дней выдать отчет по его обследованию. 2 дня Вам выделяется на работу на объекте и 3 дня на подготовку отчета. Вопрос что вы будете делать в 1-й день? во 2-й день? С чего начнете?
Вот на эти вопросы и дает ответ технология. Иногда отсутствие технологии компенсируется личным опытом того, кто проводит обследование предприятия. У него выработалась своя технология.
А вот для тех, кто первый раз ее проводит - технология то и нужна.
"Печать некого документа - это следствие, а причина это выполнение операции, например "Прием заказа"."
Операции ближе к входу бизнес-процесса - это, значит, причины , а ближе к выходу - это, значит , следствия . Так ?
Это Ваше личный подход к декомпозици бизнес-процесслв ?
Может быть , ссылки какие-то приведете.
О сроках. Сроки всегда нужно закладывать: а) реальные для качественного выполнения работ, б) с запасом.
Я всегда, оценив какую-либо работу, умножаю на 2 и время и стоимость...
1. Вся работа отдела из 10 человек состояла в получении и забивании "циферок" в экселевские формы. - ее можно было свести к минимуму и оставить всего 1-2 операторов но с нормально зарплатой (не 8000 руб., а 20000-25000 руб.) или вообще все сделать через web-интерфейс с аккамуляцией данных сразу в Москве.
2. Сбор и анализ данных по расплывчатым инструкциям. Причем строгой (в "математическом" смысле, с поэтапной с экранами и т.п.) инструкции по заполнению того или иного отчета как не было, так и нет. И при уходе человека в отпуск начинается тихая паника у начальника и страх сотрудниц - "на кого кинуть эту муть".
В налоговой то же самое: ИФНС по Санкт-Петербургу. Единственное отделение где выполняется регистрация организаций и ИП и их изменение, ликвидация и т.п. Операционисты - зарплата 6000-12000. Четких инструкция по правилам, есть каие-то общие правила, оформления входных документов нет. И операционисты исходя из собственного опыта и настроения подсказывают особо явные ошибки. Можно было бы сделать все это через web-интерфейс с автоматической проверкой всех данных.
Сайт госуслуг вроде бы этим и занимается, но все равно после заполнения всех пунктов идет ручная проверка - а это значит четких инструкций нет.
P.S. Все зарплаты до уплаты НДФЛ.
А насчет верю - не верю. Посмотрите на прикрепленные файлы
Тогода, всё, должно было бы быть не так уж страшно. При той степени продвинутости презедента, о которой Вы говорите, наверняка, был документ "Соглашение о моделировании", в котором оговаривались толщина, цвет линий и прочих элементов модели. Всё это настраивается в АРИСе.
1 ошибка: пробел между буквой "П" и цифрами "01"
2 ошибка: слово "звонок" с маленькой буквы
3 ошибка: не правильное окончание слова "клиента"
4. "П01 Звонок клиенту" не является процессом ;-)
О чем статья?

Просмотры 17831
Загрузки 0
Комментарии 83
Создание 03.04.13 15:19
Обновление 03.04.13 15:19
№ Публикации 181109
Рубрики
Практика учета,
Бизнес-процессы,
Управление проектом
Кому Для всех
Тип файла Нет файла
Платформа Не имеет значения
Конфигурация Не имеет значения
Операционная система Windows
Страна Россия
Отрасль Не имеет значения
Налоги Не имеет значения
Вид учета Не имеет значения
Раздел учета Не имеет значения
Доступ к файлу Бесплатно (free)
Код открыт Не указано

