Особенности национального управления бизнес-процессами на примере веб-студий
О том, что универсальных рецептов не существует, но есть с кого брать пример Дата публикации: 24.04.2017 Хотя аббревиатура BPM (англ. Business Process Management) по-прежнему знакома не всем, в жизни каждой студии рано или поздно наступает момент, когда необходимость системного управления бизнес-процессами становится более чем очевидна. Сегодня мы решили поговорить о том, в каких случаях такая система действительно нужна и на какие моменты следует обратить внимание в первую очередь. Необходим сайт, мобильное приложение, услуги по SEO или контекстной рекламе? Тендерная площадка WORKSPACE поможет выбрать оптимального исполнителя. База проекта насчитывает более 10 500 агентств. Сервис работает БЕСПЛАТНО как для заказчиков, так и для исполнителей. Мы начинаем BPM. Для чего? Для кого? Мы решили начать с главного — определить, насколько системное управление бизнес-процессами в целом свойственно студиям Рунета и как все происходит на практике. Вы скажете, а что там узнавать, и так ясно — в основном все делают как попало, прикладывая к проблемным местам подорожник. А мы ответим — ну не скажииите! Оказалось, что стремление к системности присуще многим компаниям. Другое дело, что не существует общепринятой системы, подходящей сразу всем студиям. И тем интереснее узнать, кто какой подход практикует. Ольга Баранцева, генеральный директор интернет-компании R52.RU поделилась предпосылками для создания своей системы BPM: Комментарий: Ольга Баранцева, генеральный директор интернет-компании R52.RU Необходимость в систематизации бизнес-процессов возникает в любой компании в тот момент, когда родоначальники бизнеса не успевают самостоятельно контролировать качество и сроки выполнения задач на всех этапах создания прибавочной стоимости и извлечения прибыли. То есть, если говорить о digital-отрасли, то это более 10 человек наемного персонала. Интернет-компания R52.RU с самого начала задумывалась и строилась как бизнес, то есть как инструмент зарабатывания прибыли, в целом не зависящий от наличия (отсутствия) конкретных талантливых персон. В настоящее время R52.RU — агентство полного цикла, оказывающее весь спектр digital-услуг, в компании работает 60 человек, количество действующих на настоящий момент договоров превышает 1100 шт. Поэтому для нас наличие стандартных процедур жизненно необходимо. Это как в биологии или кибернетике: в здоровой системе стандартный внешний или внутренний раздражитель должен вызывать стандартную реакцию (ответ, рефлекс). В этом залог устойчивости и эффективности всей системы. Данный подход иллюстрирует мнение многих руководителей. Но вот еще небольшой, но жирный акцент от Алексея Шишкина, генерального директора Redsoft: Комментарий: Алексей Шишкин, генеральный директор Redsoft Никогда не понимал, зачем в digital-разработку на проекты на 3–6 месяцев студии тянут «взрослые» методологии вроде BPMN или UML, которые используются для проектирования больших ИТС и регламентов к ним. Основная задача любой документации — аккумулировать и синхронизировать знания по проекту между участниками проекта. Без понимания всеми ключевыми участниками проекта используемого языка проектирования теряется смысл в использовании такого инструмента. Так же, как и ТЗ, написанное на суахили и подписанное клиентом будет иметь некоторую юридическую ценность, но сомнительную практическую. В противном случае требования к квалификации партнеров по проекту будут почти всегда выше реальных, со всеми вытекающими последствиями. Я считаю, что использование «тяжелых» инструментов для внутренних проектов, допустимо только в случае заранее полученного знания (при переходе разработчиков из компаний вроде Епама и Люксофта в агентство), но развивать внутри студии такие компетенции не рентабельно, пока нет перспектив получить проекты уровня сайта Олимпиады или Госуслуг. В остальных случаях достаточно простых и понятных регламентов в GDocs или корпоративной Wiki. Итак, если суммировать оба предыдущих мнения, подтверждается мысль о том, что BPM необходим прежде всего там, где большой коллектив, масштабные проекты или количество клиентов приближается к сотне в год. Крупные проекты: специфика и подводные камни Отгадайте, что мы сделали после полученных вводных? Все банально — обратились именно в те студии, которые отвечали за разработку сайтов gosuslugi.ru и веб-проектов, посвященных Олимпиаде 2014. Вдруг кто-то мечтает повторить их подвиг… Итак, Олимпиадой занималась Articul Media Group, которая известна своей причастностью ко многим крупным проектам, что само по себе предусматривает наличие процессов и эффективной внутренней системы постановки задач. В данном случае, к этой, уже работающей системе были подключены все ключевые лица. Через нее они могли ставить задачи (tikets), после чего менеджер переводил эти задачи после обработки во внутренние задачи рабочим группам (tasks). Там же для клиента строились отчеты по затраченным ресурсам. Насколько нам стало известно, система была эффективна настолько, что заказчик олимпийского проекта даже попросил ее внедрить к остальным подрядчикам. Кроме того, в агентстве на каждом проекте принято делать матрицу ответственности и коммуникационную матрицу. Таким образом всем участникам проекта понятно, кто с кем и по каким вопросам общается, и кто за какие решения отвечает. Допустим, студии удалось изначально создать масштабируемый и жизнеспособный продукт. Но как же индивидуальный подход? Неужели ничего даже «шлифовать» не понадобилось? К сожалению, универсальных рецептов нет. Понадобилось! Комментарий: Чуть ли не единственное, что мы сделали специально — написали свою систему управления требованиями и систему комментирования дизайна и верстки. Рабочая группа по созданию сайта Олимпийских Игр выглядела так: IT-департамент Организационного Комитета Игр; департамент маркетинга Организационного Комитета Игр; мы, как создатели требований к сайту, дизайна и front-end; команда Microsoft, как главный подрядчик по back-end. В какой-то момент стало понятно, что ни почта, ни наша система постановки задач для управления работой над требованиями и дизайном не подходит из-за множества лиц, участвующих в согласовании и огромного кол-ва документов и макетов. Внешних инструментов мы не нашли и написали быстро свое. Эти системы очень нам помогли быстро работать и согласовывать требования к сайту, макеты и верстку при таком количестве вовлеченного народа. Выглядело это так: в меню (левая колонка на рисунках) были перечислены все необходимые документы и макеты, в систему загружался документ или макет, все комментировали. Дальше мы шли на второй круг и снова: загружался документ или макет, и все комментировали. Если документ или макет принимался — ставилась галочка «Принято» и эта ветка закрывалась. Сейчас мы тоже используем данные инструменты для нашей работы. С разрешения Ольги мы вырезали скриншоты с их системы. Инструменты управления: требования Но это конкретный кейс. А есть ли общие рекомендации для тех, кто впервые замахивается на масштабные проекты или желает сделать эту практику более эффективной? С ответом на этот вопрос нам помог Сергей Попков, основатель AIC (именно эта компания и занималась пресловутыми госуслугами). Вот, какие советы он дал для руководителей проектов, в которых есть от трех и более заказчиков: Всегда добивайтесь съема требования (брифинга) у реальных представителей бизнеса. А не у маркетолога, менеджера интернет-проектов. Не отправляйте дизайн-макеты по почте. Это только усугубляет положение. Презентуйте решение лично. И только лицу, принимающему решение. Если их много, еще лучше. Всем сразу. При этом Сергей обращает особое внимание на небольшую, но важную деталь: Комментарий: Сергей Попков, основатель AIC Очень часто вам, конечно, говорят, что эти лица крайне занятые. И мы с ними уже все обсудили. Вся инфа от них есть. Так вот уже на этом этапе, вероятность что данные сняли неправильно и задача может быть плохо сформулирована — вырастают в разы. Теперь представим, что у нас 10 представителей бизнеса. Разные департаменты. Разные цели. Разные разделы на сайте. Как быть? Сергей, опираясь на собственный опыт, выдал практически готовый чек-лист: Комментарий: Сергей Попков, основатель AIC Вначале делаете очное интервью с каждым из них по отдельности. Это уже не просто. Но если будете наставить, вам могут пойти навстречу. У нас с этим проблем не было. Говорим — сами соберем все входящие, разложим по полочкам. Вам же потом будет проще. Все стрелки на нас переводить будете (это для маркетологов и менеджеров интернет-проектов). Они обычно трясутся перед руководством. А мы с ними говорим на одном горизонте. Нам бояться-то нечего. После интервью, собираем все в адекватный документ. Обычно презентация с ключевыми тезисами каждой из сторон. Складывается картина мира. И уже есть понимание между кем и кем по интересам возможен конфликт. Проводим общий вводный воркшоп. Это самое сложное. Всех собрать. Но и одновременно самое эффективное. Программа воркшопа это отдельная и большая тема. Сюда не влезет. Коротко за один день наша рабочая команда со всеми представителями бизнеса обсуждает, спорит и согласовывает план действий. Структуру нового продукта/сайта. Тренды в дизайне. Вероятно, и уже какие-то наброски концепты по идеям. В итоге мы уходим, когда гарантированно все между собой договорились. Обычно на выходе получается самый шикарный результат. Заказчик уже чувствуют наши сильные экспертные позиции. Не играется со шрифтами. Мы комфортно и качественно делаем свою работу. Эффективным инструментом также являются еженедельные планерки с минимумом представителей заказчика. Но тут все зависит от степени вовлеченности. К примеру, на проекте госуслуг, в среднем на еженедельной планерке от заказчика присутствовало 8 человек. ПО: какое выбрать? Все такое вкусное, такое вкусное Итак, либо ваша студия — совсем небольшая и можно расслабиться/держать все в свой голове, либо вы понимаете, что уже доросли до уровня, когда необходимо срочно что-то регламентировать и систематизировать. Какое ПО используют коллеги? Отвечает Александр Друзь… А, нет, простите, отвечает Алексей Соловьев, директор по развитию рекламного интернет-агентства x10: Комментарий: Алексей Соловьев, директор по развитию рекламного интернет-агентства x10 Для систематизации собственных процессов мы используем две CRM-системы и регламенты. В нашей компании работает 10 человек и этого количества сотрудников нам пока достаточно для грамотной работы. Продажи вынесены в отдельную CRM-систему. Проекты, базу клиентов и регламенты мы ведем в собственной CRM. Думаю, без CRM и регламентов мы бы не смогли успешно работать. Их внедрение было обусловлено увеличением клиентов и рисками потери контроля. Для сравнения давайте посмотрим еще на одну крупную компанию, чье портфолио преимущественно занимают крупные и государственные проекты. Николай Апурин, генеральный директор крупного веб-интегратора ООО «АРТВЕЛЛ» был лакончен: Комментарий: Николай Апурин, генеральный директор крупного веб-интегратора ООО «АРТВЕЛЛ» Все крупные внедрения на Java мы ведем по стандарту JBPM. Проекты же на PHP отлично управляются из Битрикс 24. Этот сервис закрывает 99% всех задач. Не надо изобретать велосипед, в Битриксе уже все отлажено. Узкий камень только один — человеческий фактор. Решается путем двойного контроля за каждым руководителем проектов. А вот если мы говорим о крупной разработке, в которой более 30 человек, то уже в бой идет Redmine, JIRA, git и т.д. Обратили внимание? В то время как крупному веб-интегратору по сути хватает одной системы, студия, разрабатывающая менее масштабные проекты, использует сразу несколько CRM. Странность?! Кстати, тот же AIC использует для мониторинга и работы над проектами довольно простые решения: Excel c отчетами, Basecamp для таск-трекинга и Harvest для трекинга времени. И все это замиксовано с Mailchimp и «Битрикс24» (причем Битрикс 24 больше используется именно для телефонии). Впрочем, да что мы все о «Битрикс 24». Есть же и другие варианты. Пожалуй, будет не объективно с нашей стороны, если мы не укажем каких-то альтернатив. А они ведь есть! Так как мы внимательно следили за тем, как три года назад Greensight искал подходящую CRM, то мы решили обратится именно к ним с вопросом — какую именно систему они выбрали в итоге, почему и, главное, не пожалели ли потом. Комментарий: Егор Волков, сооснователь и генеральный директор Greensight Три года назад, когда мы в очередной раз выбирали CRM для продаж в Greensight, мы остановились на системе Pipedrive. На тот момент все CRM, с которыми мы подробно были знакомы (amoCRM, Bitrix24, Base, Highrise, Мегаплан и еще с десяток платформ) нас не устраивали. Либо сложностью и запутанностью интерфейса и функциональности, либо отсутствием гибкости в настройках, либо отсутствием простых отчетов, либо интеграций с сервисами Google и т.п. С тех пор многие системы развились в нечто напоминающее Pipedrive. Так, например, amoCRM при первой глобальной смене интерфейса многое переняли у «пайпа». Bitrix24 теперь также хорошо доработали с точки зрения представления движения сделок от лида до подписания. Однако, мы уже хорошо сработались с нашей CRM и вряд ли её поменяем на что-то другое. Недавно после последнего обновления посмотрел возможности модуля CRM в Bitrix24. Огромное море возможностей, но лично мне кажется, что интерфейс всё-таки сложный, много лишних функций, не очевидно использование системы в режиме «сел и поехал». Справедливости ради стоит заметить, что Bitrix24 — идеальный корпоративный портал, которым мы пользуемся для инфокоммуникационной деятельности в Greensight. Настроен ряд бизнес-процессов. В таком использовании ему нет равных на рынке, особенно в соотношении цена-качество. Словом, CRM — это уже давно не дань трендам, это жизненная необходимость для большинства студий. Именно за счет эффективного использования CRM можно оптимизировать процессы и нарастить продажи. Вопрос только в том, какая из доступных систем лучше закрывает потребности конкретного бизнеса. Как это происходит на практике? Ознакомившись с несколькими историями, мы пришли к выводу, что внутренняя кухня R52 отлично подходит в качестве примера и попросили Ольгу рассказать подробнее о внутренних алгоритмах работы и регламентах. Она обозначила, что все их бизнес-процессы разделены на общие большие блоки и соответствуют организационной структуре: новые продажи, поддержка клиентов, филиалы, веб-продакшн, хостинг-администрирование, интернет-маркетинг, PR, HR, финансы, АХЧ. Схема взаимодействия и алгоритм взаимодействия между блоками и внутри блоков описываются специальными регламентами, в которых указана последовательность необходимых действий соответствующего сотрудника в конкретной ситуации, а также сроки реакции и критерии завершения процесса. Примеры таких внутриблоковых регламентов: — обработка входящей заявки; — передача дизайн-макета в верстку с описанием сценариев; — обязательные действия SEO-специалиста при поступлении нового проекта; — минимальный ежемесячный набор действий PR-менеджера и т.д. Примеры документов, описывающих и систематизирующих междублоковые и общефирменные бизнес-процессы: — общий регламент планирования компании R52.RU (стратегического, тактического и оперативного); — регламент взаимодействия между коммерческим отделом и отделом поддержки клиентов с подразделениями производства; — передача проекта в отдел поддержки клиентов; — правила передачи проектов и задач в период отсутствия основного сотрудника (отпуск, б/л, увольнение); — программа адаптации нового сотрудника и другие. Комментарий: Ольга Баранцева, генеральный директор интернет-компании R52.RU Создание нового регламента (а также внесение исправлений в существующий) инициируется директором по персоналу на производственном совещании на основании принятого годового плана, или как реакция на какой-либо инцидент. Работа начинается с описания бизнес-процесса и указания участников, затем выстраивается последовательность действий ответственных лиц и формулируются критерии окончания процесса и оценки результата. Модератором процедуры написания и внедрения регламента является директор по персоналу. Внутриблоковые регламенты создаются начальниками подразделений с привлечением ведущих специалистов с учетом пожеланий других отделов. За написание междублоковых регламентов отвечает сам директор по персоналу, т.к. в них приходиться учитывать интересы разных служб (зачастую противоположные) и нужно искать компромиссные решения в интересах компании. Все регламенты утверждаются гендиректором, после чего выкладываются в соответствующий раздел в CRM. О всех новых регламентах и изменениях в существующие сотрудники уведомляются посредством спецрассылки и на совещаниях в отделах. Контроль за исполнением лежит на начальниках подразделений. Неисполнение регламента влияет на KPI сотрудников, их непосредственных руководителей и некоторые коэффициенты при начислении зп. В целом хочу отметить, что систематизация бизнес-процессов — это не самоцель и не панацея от всех организационных и финансовых проблем. Это один из инструментов управления компанией. Но не стоит доходить до маразма и пытаться забюрократизировать, стандартизировать и описать «всё и вся». Все хорошо в меру, в нашем бизнесе важно оставлять людям возможность для творчества и импровизации. Систематизация необходима только для циклических (постоянно повторяющихся) процессов, требующих на выходе стандартный результат. Итак, в конце еще раз, это важно: систематизация необходима только для циклических (постоянно повторяющихся) процессов, требующих на выходе стандартный результат. Важно не удариться в крайность, когда бюрократия не помогает, а вредит. Автор: Катерина Логвинова, CMS Magazine & «Рейтинг Рунета» (Директор по коммуникациям) Please enable JavaScript to view the comments powered by Disqus.Полный текст статьи читайте на CMS Magazine
