Инструкция по осмыслению и описанию своих процессов для подрядчика на примере CRM.
2188 просмотров
Для кого: Тем, кто думает про внедрение CRM (или другой системы), а платить за проработку своих бизнес-процессов не хочет, или не видит смысла, или считает что у него «как у всех»). При этом, вам хочется понять точную цену, а не «от».
Чем полезно: Cнизите риск переплатить при внедрении CRM с недобросовестными подрядчиками и повысите шанс успешного внедрения с первого раза. Поймете лучше свой бизнес, а исполнитель лучше поймет вас)
Без ТЗ — результат ХЗ
Народная мудрость
Как показывает наша практика, эту мудрость знают все, но представление о ТЗ у клиента и исполнителя сильно разнится.
Как разработать Техническое задание. Часть 2. Виды работ при сборе требований к системе учета и информации для описания бизнес-процессов
Техническое задание #2 — Видение и бизнес-процесс
2012-07-16 в 5:07, admin , рубрики: техническое задание, управление проектами, метки: техническое задание
Первая часть статьи «Разработка технического задания «Что это такое, зачем оно нужно, с чего начать и как должно выглядеть?» вызвала немалый интерес. Кроме своей рассылки, я ее опубликовал и на известном сайте разработчиков Инфостарт, где она вызвала еще больший интерес, что не может не радовать. Как и обещал, пишу продолжение.
Хорошо подумав, я решил, что вместить весь материал планируемой второй части в одну статью опять не получится, иначе это будет верхами и в теории, что и так написано во многих учебниках. Но ведь я ставлю задачу, чтобы это можно было применять на практике, поэтому не буду больше загадывать на будущее о том, сколько выпусков еще потребуется, чтобы закончить с темой. На это будет влиять и обратная связь с читателями, так что пишите, не стесняйтесь!
Пользуясь случаем, хочу задать вопрос: на сколько интересна была бы организация практического семинара-тренинга в Санкт-Петербурге на тему разработки Технического задания? Встретились бы, опытом обменялись. Если такой интерес будет не единичным, обещаю организовать.
Поскольку читателями являются не только специалисты в области разработки программного обеспечения, а также бизнес-аналитики и руководители различного уровня, постараюсь писать так, чтобы было интересно всем.
В этой части мы будет говорить о том, как организовать этап работ по сбору требований, из чего он должен состоять и какими инструментами можно пользоваться. Повторюсь, что данные работы с точки зрения этапов очень похожи на обследование предприятия с целью описания бизнес-процессов.
Как обычно происходит в жизни:
С чего начать описание бизнес процесса? Простая анкета вместо тех задания.
| Как это происходит в большинстве проектов | |
| Шаги | Как это происходит |
| Решение принято, проекту быть! | Понятное дело, что есть повод для радости, особенно, если проект большой, ничего плохого в этом нет! Главное, не радоваться слишком долго, оттягивая начало фактических работ, с этой минуты время будет идти по-другому. |
| Провели совещание с руководителями, собрали некоторую информацию об их видении результата. | Обычно этот процесс ограничивается несколькими встречами с руководством, затем с руководителями подразделений. Зафиксировав некие «позывы» со стороны Заказчика, они фиксируются в виде общих формулировок. Иногда к этому добавляют имеющуюся документацию (кто-то когда-то пытался уже поводить обследование, документы по существующим регламентам, формы используемых отчетов) Как ни удивительно, но после этого большинство внедренцев систем автоматизации радостно восклицает: «да в нашей системе все это есть! Ну немного поднастроить и все будет работать». На вопрос, надо ли обсуждать, как все должно работать (или как выполняется конкретный процесс) с конечными пользователями, ответ обычно отрицательный. Высказывается мнение, что руководитель все знает за своих подчиненных. А зря… За этим скрывается множество ловушек и препятствий, и сдача работ может превратиться в марафон по полосе с препятствиями. Как известно, марафон принято бегать по ровной дороге, а бег с препятствиями возможен только на коротких дистанциях (можно и не добежать). |
| Документирование результатов работы | После этого начинается документирование результатов в зависимости от целей работ: Если требуется разработать Техническое задание, консультант начинает рассовывать полученную информацию по заготовленному шаблону документа, чтобы и выглядело красиво, и основные требования были зафиксированы (те, что озвучены от руководства, а то ведь могут не утвердить). Понимая, что на практике такое Техническое задание особо не используется и приходится все выяснять «по ходу дела», главной целью Технического задания он ставит минимальное время согласования и утверждения. И, если получится, информация для примерной оценки стоимости будущих работ (кстати, тоже немаловажно). Если требуется описать бизнес-процессы. Как ни странно, но часто все предшествующие действия выглядят аналогично, как и в случае с разработкой Технического задания. Разница лишь в оформлении документации. Тут возможны варианты: консультанты описывают процесс произвольными словами или используют какие-либо правила описания бизнес-процессов (нотации). В первом случае такой документ получается удивительным образом похож на Техническое задание. Бывает даже такое, что если заменить титульный лист, никакой разницы не увидишь.В последнем случае часто делают акцент не на соответствии действительности, а на «правильности описания», т.е. формальное следование правилам описания.К сожалению, оба варианта являются не самой лучшей практикой, т.к. являются скорее формальностью, а пользы приносят не много. |
Почему сложилась такая практика, как описано выше? Признаться, я не знаю. У кого ни спроси, никто не знает. При этом ситуация меняется не очень быстро, хотя на эту тему постоянно дискутируют, обмениваются опытом, пишут книги… Мне кажется, что одна из причин – низкое качество соответствующего образования.
Может еще сказывается и тот факт, что много специалистов приходит вообще их другого бизнеса, и постигают все на практике, т.е. их опыт формируется в той среде, куда они попали. Об отношении ВУЗов и отсутствия их стремления быть ближе к реальности, тоже факт известный, но меня иногда удивляет их позиция. Например, у меня был случай, когда дипломница, талантливый специалист, хотела писать дипломную работу на платформе 1С (хорошую отраслевую разработку), но на кафедре ей сказали, что независимо от темы, на оценку «отлично» рассчитывать будет нельзя, т.к. 1С несерьезная система. Тут дело не в серьезности и объективности такого мнения, а в том, что примитивное задание на классическом языке программирования тут же считалось достойным оценки «отлично».
Давайте попробуем придать рассмотренному выше процессу более системный подход. Как он может тогда выглядеть?
Как видим, процесс заканчивается вопросом, т.к. на этом работа далеко не закончена и дальше начнется самое сложное и самое практичное – именно то, что будет определять применимость полученного результата в реальной жизни. Именно то, что будет определять судьбу предыдущей работы: или она отправится в шкаф (на полку или еще куда-нибудь), либо будет представлять собой ценный источник информации. А еще лучше, если она станет образцом для последующих проектов.
Хочу особо отметить, что до последнего шага на схеме (там, где вопрос) общий принцип сбора информации о деятельности компании выглядит одинаково, независимо от того, что планируется делать в дальнейшем, описывать бизнес-процессы или внедрять автоматизированную систему. Да, сама последовательность шагов одинаковая, но инструменты, применяемые на некоторых из них, могут отличаться. Мы данный момент обязательно рассмотрим, когда будем изучать методики и инструменты отдельных этапов. Подробно будем это делать в отдельных статьях, а сейчас рассмотрим только самое главное. Дальнейшие шаги будут отличаться и определяться тем, что требуется от проекта: описать бизнес-процессы или внедрять систему учета.
Давайте посмотрим, как можно реорганизовать подход к сбору информации о деятельности компании.
- В первую очередь тем, как Вы обучили проектную группу Заказчика. Они должны четко понимать, как происходит процесс анкетирования и уметь донести информацию до всех участников
- Сама форма анкет. Анкеты должны быть понятными. Желательно, чтобы была инструкция по заполнению анкет. Еще лучше, если будет пример заполнения.
- Состав участников. Необходимо правильно выбрать состав участников. Если ограничиться только руководителями, собрать достоверную информацию не получится. Я рекомендую включать в состав анкетирования всех, кто будет в будущем являться пользователем конечных результатов. Например, если речь идет о внедрении автоматизированной системы, то стоит включить всех, кто будет являться пользователем. Бывают случаи, когда из 10 сотрудников одной должности найдется один, который выполняет какую-нибудь особенную функцию, о которой никто из оставшихся 9-ти больше не знает (например, готовит особый отчет для руководства). Если речь идет о дальнейшем перераспределении обязанностей или разработке должностных инструкций, следует поступить аналогично.
Вот и добрались до вопроса «Что дальше?». Дальше будем рассматривать задачи описания бизнес-процессов и разработки Технического задания отдельно. Я не случайно рассматриваю эти задачи параллельно. Между ними действительно много общего, что я и хочу продемонстрировать. Сначала рассмотрим последовательность работ при описании бизнес-процессов.
| Шаги | Что и как делать |
| Выделяем бизнес-процесс | Из общего перечня бизнес-процессов, полученного на предыдущих этапах, выделяем один (по приоритету) для детальной проработки. С остальными затем поступаем аналогично. |
| Детальное изучение бизнес- процесса | Выделенный бизнес-процесс подвергаем детальному изучению: анализируем полученные первичные документы, отчеты и их структуру, используемые в процессе программы, различные файлы (например, Excel), разговариваем с конечными исполнителями. Собираем различные идеи о том, как можно улучшить процесс. Очень полезно, если удастся понаблюдать за процессом именно в тех условиях, в которых он выполняется (не многие любят, когда за ними наблюдают, но что делать) |
| Графическое и/или текстовое описание бизнес-процесса (первичное) | Полученную подробную информацию начинаем описывать.Прежде чем описывать процесс, надо определиться, потребует ли он графического описания. Если процесс простой и понятный, функций в нем мало, и, графическое представление не улучшит его понимание или восприятие, то не надо тратить на это время. В этом случае достаточно описать его в текстовом виде в табличной форме. Если же процесс сложный, с различными логическими условиями, то лучше привести его графическую схему. Диаграммы всегда воспринимаются легче. Если Вы решили описать процесс в графическом виде, это вовсе не означает, что не надо приводить его текстовое описание. Т.е. текстовое описание процесса должно быть в любом случае, причем выполненное по одинаковой схеме. Удобно это делать в виде таблицы, в которой указать: исполнителей каждого шага, какую информацию они получают на входе, описание каждого шага, какую информацию формируют на выходе. Ниже мы посмотрим на примере, как это может выглядеть. |
| Согласование с исполнителями и владельцем бизнес-процесса | Лучший способ понять, насколько удачно вы выбрали стиль изложения информации, это показать результат пользователям (исполнителям) процесса.На самое главное в такой демонстрации это понимание того, насколько правильно Вы поняли, как процесс выполняется.Если обучение проектной команды прошло успешно, то можно ожидать от исполнителей вполне адекватной обратной связи. А если им станет интересно, то продвигаться все начнет гораздо быстрее.Выявленные уточнения и несоответствия необходимо отразить в описании (актуализировать), при необходимости операцию повторить. |
| Выделение показателей бизнес-процесса | После того, как выработано правильное понимание, как выполняется бизнес-процесс, надо подумать над показателями, которыми можно измерить качество или скорость выполнения процесса. Это не просто, но необходимо. Показатель должен быть измеряемым, т.е. выражен в числовом выражении и должен существовать простой способ эту величину получить. Если измеряемый показатель выделить невозможно, есть риск того, что бизнес-процесс выделен неудачно. Кроме того, не будет возможности понять (измерить ведь нельзя), приведут ли изменения процесса к его улучшению или нет. |
| Окончательное документирование бизнес-процесса | После того, как мы убедились в правильном понимании, как процесс выполняется (или должен выполняться), можно включать его в документацию. |
| Дальнейшие действия (или их отсутствие), в зависимости от целей проекта | Дальше возможны варианты: рассматриваемые процессы будут анализироваться и оптимизироваться, разрабатываться должностные инструкции, приниматься решения о необходимости автоматизации отдельных процессов и т.д.Это может быть и отдельный проект: описание бизнес-процессов. |
Теперь рассмотрим, как будет выглядеть подход к изучению требований к информационной системе с дальнейшим их отражением в Техническом задании
- А что, если планируется разработка новой системы и моделировать попросту не в чем?
- Что, если для демонстрации не хватает функциональности, и систему надо дорабатывать?
Конечно, Вы должны столкнуться с такой ситуацией, и это нормально. Что делать? Если система совсем новая (как говорится «с нуля»), то моделировать придется по большей части на бумаге, тут Вам диаграммы вариантов использования очень помогут. Частично имеет смысл набросать некоторые экранные формы, которые предполагается разработать (прямо в той среде, в которой будет вестись разработка), т.к. рисовать их в каком–нибудь редакторе будет дольше и эта работа скучная.
Если внедряется готовая система, и в ней не хватает функциональности, то ничего страшного нет, данные вносятся руками, а пользователю так и рассказывается, что после необходимых доработок должно рассчитаться так-то и так (и он это видит).
Да, разработка Технического задания процесс трудоемкий, а значит и затратный. Но если он сделан грамотно, то избавляет Заказчика от не сбывшихся ожиданий. Исполнителю приходится делать то, что требуется Заказчику и не переделывать сто раз одно и тоже. Да и вообще, придает всему проекту прозрачность.
Источник: www.pvsm.ru
Составление технических заданий при передаче бизнес-процессов на аутсорсинг глазами провайдера
2016 год явился переломным для рынка аутсорсинговых услуг, в той или иной степени связанных с человеческими ресурсами. После вступления в силу закона №116-ФЗ по ограничению заёмного труда некоторые компании пришли к решению своих бизнес-задач в рамках этого закона, другие полностью отказались от аутсорсинга, переведя процессы и сотрудников под собственную юрисдикцию, третьи начали искать обходные пути. Лишь немногие стали ориентироваться на аутсорсинг бизнес-процессов (BPO). Однако переход от прямого использования заёмного труда, запрещённого теперь законом, к новым легальным моделям взаимодействия – процесс сложный, требующий серьёзных усилий как со стороны заказчика, так и со стороны провайдера.
По оценке экспертов кадрового агентства Юнити, большинство желающих использовать в своей деятельности BPO сталкиваются с трудностями ещё на этапе проведения тендера, а именно – при составлении технического задания.
Изначально корень проблемы в том, что заказчики, условно ориентируясь на аутсорсинг бизнес-процесса, предполагают оставить за собой некоторые функции, которые в реальном BPO должны быть в зоне ответственности исключительно провайдера
Это прежде всего оперативное управление персоналом, контроль управления качеством, обучение персонала (как непосредственно рабочим процессам, так и безопасным навыкам ведения работ, стандартам качества), проверка знаний и навыков, мотивация персонала и др.
Для того чтобы провайдер мог сделать взвешенное коммерческое предложение, техническое задание должно включать в себя не только общее описание процессов, объёмов и сроков работ, но и те детали, которые дадут исполнителю возможность оценить себестоимость процесса и оказать услугу, отвечающую принятым KPI, таким как выполнение требуемых работ в установленное время в соответствии с критериями безопасности и качества.
К таким деталям относятся:
- Объёмы работ в измеряемых единицах. Для некоторых процессов это могут быть нормо-часы, для других это количество собранных заказов, отгруженных машин, обслуженных посетителей, убранных площадей и т.п.
- График работы. Стоимость работ, выполняемых в режиме 40-часовой рабочей недели, будет существенно ниже стоимости работ, выполняемых в режиме 24х7. Оплата труда в выходные и праздничные дни, в вечернее и ночное время, а также за пределами установленного рабочего времени прямым образом повлияет на себестоимость процесса в целом.
- Возможные сезонные, недельные, дневные колебания объёмов, а также длительность всплесков и падений и время оповещения. Если колебания невелики и/или предсказуемы, то у провайдера есть возможность иметь обученный резервный персонал, который будет задействован по мере необходимости, и это не слишком сильно повлияет на стоимость процесса. В других случаях, особенно если для выполнения работ требуется персонал определённой квалификации, придётся оплачивать сверхурочную работу, что на стоимость процесса повлияет уже существенно.
- Зоныконтрактнойи финансовой ответственности провайдера, а также штрафные санкции, если они предусмотрены. Легальные и финансовые риски существенно повлияют на размер вознаграждения провайдера.
- Площадка, на которой предстоит работать, а именно:
– её удалённость от населённых пунктов, т.е. провайдер должен оценить затраты на ежесменную или одноразовую (в случае вахты) доставку к месту работы, стоимость проживания;
– специфические требования к медосмотрам и медкнижкам;
– условия труда, особенно если потребуется доплата за вредные и опасные условия либо дополнительный оплачиваемый отпуск;
– условия труда также повлияют на состав СИЗ.
- Техника, с которой предстоит работать, в следующих основных аспектах:
– какие сертификаты и лицензии должны быть у работников, её использующих;
– насколько усложняет поиск персонала наличие специфических требований, как эти требования влияют на стоимость персонала;
– кому принадлежит техника, кто будет отвечать за ППР.
Провайдер, получая приглашение к участию в конкурсе на предоставление услуги аутсорсинга бизнес-процесса, должен детально проанализировать все процессы
Даже если техническое задание подробное и полное, почти всегда возникают дополнительные уточняющие вопросы. Нередко требуется предпроектное исследование, которое невозможно выполнить за короткий срок. Любой серьёзный тендер требует времени на его проработку. Если заказчик этого времени не даёт, то, скорее всего, он получит либо недобросовестного провайдера, который назначит цену «с потолка», либо по факту конечная сумма будет существенно отличаться от заявленной, и, как показывает опыт, практически всегда в большую сторону.
Также значительную опасность несёт установка максимальной цены, от которой далее торговля между участниками конкурса пойдёт вниз. В этом случае почти наверняка в приоритете будут те провайдеры, которые работают вне рамок легального поля. Их цена всегда будет существенно ниже цены легальных поставщиков.
В вопросе стоимости BPO есть ещё один аспект – единицей измерения может являться нормо-час, учитывающий не только час работы персонала, но и норматив производительности. В отличие от стоимости человеко-часа, которая не может априори быть ниже минимальной зарплаты по региону с учётом налогов и сборов, нормо-час может включать стоимость труда нескольких работников, используемых материалов, техники и т.д. Итоговая стоимость нормо-часа будет тем ниже, чем выше производительность труда.
Игра на понижение стоимости человеко-часа при выборе провайдера приводит лишь к снижению качества персонала и вынуждает исполнителя выходить из легального поля. Нормо-час, напротив, учитывает все аспекты работы, и снижение его стоимости снизит стоимость процесса в целом, не ухудшая его качества.
Чтобы свести ошибки на подготовительной стадии к минимуму, необходимо плотно взаимодействовать с провайдерами: проводить предтендерные встречи, закладывать реальные сроки и требования, оперативно отвечать на возникающие вопросы. Тесную связь с исполнителем не стоит терять и в ходе адаптационного периода, и после успешного внедрения проекта. Это позволит получить максимальную отдачу от аутсорсинга любого бизнес-процесса и сделать сотрудничество по-настоящему комфортным и долгосрочным
Источник: hr-media.ru
