Текст книги "Оптимизируй это немедленно! Как, используя современные IT-инструменты, сократить издержки и обойти конкурентов"

Глава 19. Методология ведения проектов

Скорость изменений нарастает, и это требует новых подходов в разработке продуктов и услуг и выводе их на рынок. Многие компании стали использовать относительно новую методологию ведения проектов – Agile. Давайте разберемся, нужна ли она вам и когда именно.

Классические методологии ведения проектов, или Waterfall (водопад), такие как «Свод знаний по ведению проектов (PMBoK)» и PRINCE II», нацелены на долговременные проекты с фиксированной конечной целью: есть описанная целевая функциональность продукта, которой необходимо достичь, цели проекта, далее оцениваются необходимые ресурсы для достижения цели, последовательность действий, которые необходимо предпринять, составляется план проекта, фиксируется устав, формируется команда, и проект начинается. Классические методологии, как правило, содержат следующие стадии: анализ, дизайн, разработка, тестирование, внедрение, опытно-промышленная и промышленная эксплуатация и поддержка продукта. При этом целью может быть как создание нового товара или услуги или развитие нового направления, так и внедрение программного продукта (например, учетной системы). Ключевую роль играют факторы предварительной оценки и руководства проектом: предварительно очень сложно оценить функциональный объем проекта – всех нюансов не учтешь, к тому же во время внедрения всегда уточняются и дополняются требования к системе: что-то не учли во время предварительного обследования, что-то забыли, о чем-то не подумали, и к тому же во время внедрения появляются новые требования к системе. Все это ведет к дополнительным затратам на разработку, временным и финансовым. Именно поэтому данная методология очень забюрократизирована и требуется много усилий, чтобы прописать каждую галочку и настройку, а проектная документация может насчитывать несколько томов даже на небольшом проекте. Кстати, если для вас, а тем более для подрядчика, подобный проект в новинку, очень рекомендую заранее заложить как минимум 30 % дополнительных денежных средств и времени на непредвиденные обстоятельства и дополнительные доработки, которые выявятся по ходу проекта. И это еще оптимистичная оценка: я знаю случаи, когда итоговый бюджет проекта в разы превышал первоначальный. Здесь очень важна роль руководителя проекта (РП), ведь ему необходимо добиться целей проекта, запуска всей функциональности и сделать это в отведенный срок и бюджет имеющимися у него ресурсами. Фактически он может влиять только на ресурсы – мотивировать, попросить ускориться, контролировать своевременность выполнения поставленных задач, привлекать дополнительные ресурсы (хотя это может отразиться на прибыльности и качестве проекта). Подавляющее большинство подобных проектов продается по фиксированной стоимости, поэтому важно следить не только за достижением целей проекта, но и за экономикой, но зачастую от экономии может пострадать как раз качество. К тому же много усилий требуется на урегулирование спорных ситуаций, ведь, как говорится, «однако за время пути собачка могла подрасти»: объем проекта имеет склонность к расширению именно во время разработки и внедрения, а цена контракта фиксирована. Вдобавок заказчик порой уверен, что подобная функциональность уже входит в поставку, и бывает крайне разочарован, когда ему показывают план проекта, где этой функциональности нет, и требуют доплатить за доработку. Именно поэтому необходимо детально прорабатывать и фиксировать организационный и функциональный объем проекта, а это требует качественной предварительной проработки, что не всегда возможно или будет оплачено заказчиком.

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

Прямая противоположность – это гибкая методология разработки (Agile). Agile-методология предполагает «поедание слона маленькими кусочками»: проект разбивается на очень маленькие части – итерации. Итерация может длиться от нескольких дней до нескольких недель и представляет собой создание некого законченного продукта, который тут же можно применить или протестировать, а по замечаниям – доработать на следующей итерации. Данная методология важна, когда скорость изменений высока, продукт необходимо запустить очень быстро; к тому же цели проекта могут быть изменены прямо во время внедрения: например, в период подготовки к выводу на рынок новой услуги выясняется, что конкурирующий продукт обзавелся рядом интересных возможностей и их срочно нужно повторить в нашем продукте. А иногда во время проекта выясняется новая интересная задача, которая может существенно повысить эффективность бизнеса или привлекательность услуги, и проект переключается на ее реализацию.

Agile-методология предполагает постоянный контакт с заказчиком – владельцем продукта – вплоть до ежедневных встреч с демонстрацией промежуточного результата и обсуждением прогресса. Поэтому, если что-то идет не так или требуется разработать дополнительную функциональность, это сразу же включается в проект. К тому же в разработке Agile почти нет места документации, главная задача – быстрее выпустить новый продукт! Гибкая методология проповедует, что люди и взаимодействие важнее процессов и инструментов, работающий продукт главнее исчерпывающей документации, сотрудничество между заказчиком и подрядчиком превыше согласования условий контракта, а готовность к изменениям существеннее следования первоначальному плану.

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

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

Более того, один из крупных проектов специалисты компании Softline сделали полностью удаленно, когда это еще было в диковинку. Исполнители находились в другом регионе, да и руководству заказчика вечно не хватало времени на проектные интервью. В итоге все интервью были запланированы в календаре, когда руководству это было удобно, и были записаны с разрешения участников проекта. Если консультант что-то не понимал или в проект вводился новый сотрудник, не было необходимости дергать руководство заказчика – достаточно было посмотреть запись и задать несколько уточняющих вопросов. Это позволило не просто сократить затраты на проект, но и завершить его в рекордно сжатые сроки – от первого интервью до ввода системы в промышленную эксплуатацию в десятке отделов прошло всего несколько месяцев, а некоторые участники проекта лично познакомились с исполнителями только при запуске проекта в промышленную эксплуатацию.

Кейс 12. Почему бы все не упростить?

Если рассматривать список первоочередных проектов по оптимизации работы сотрудников, то давайте вернемся к цифре 19. 19 часов в неделю – именно столько тратят сотрудники на работу с информацией. А что, если сократить это число в 4 раза? У вас освободится ПОЛОВИНА персонала. Я помню начало работы над проектом с крупным немецким автопроизводителем в 2014 году. Кризис, всем не до аналитики – остаться бы на плаву! Автосалоны закрываются или перепрофилируются с дорогих автомобильных марок на эконом– и бюджет-класс. Но именно в этот момент и нужна аналитика – понять, что происходит, чтобы спланировать дальнейшие действия. Однако это дало и неожиданный эффект. Через несколько лет руководитель проекта со стороны заказчика на одной из конференций привела такие цифры: «До 50 % рабочего времени освободилось у сотрудников отделов, внедривших Qlik Sense, то есть 80 сотрудников из 160 человек». В зале раздался вздох, который волнами прокатился по рядам, – «Уволили?» Руководитель тогда рассмеялась: «Коллеги, у нас же запрет на найм нового персонала! А если кто-то уходит, то эту позицию закрывают, и человека нельзя нанять. В итоге сотрудники были перегружены, им приходилось работать сверхурочно. Страдало качество отчетов, люди уставали на работе, и результат был хуже. Когда у нас освободилось 80 человек, мы перераспределили рабочие ресурсы, поставили новые задачи сотрудникам. Кстати, мы впервые со времени начала кризиса 2014 года запустили маркетинговую кампанию – у нас просто не было ресурсов на такой проект! К тому же мы решили перейти на „безбумажный офис“ – теперь все отчеты идут только в электронном виде».

Кстати, проект помог и головной компании окончательно определиться с решением, и сейчас они используют систему Qlik Sense как целевую платформу бизнес-аналитики, присоединившись к своим коллегам из компаний BMW и Mercedes.

Глава 20. Грамотность работы с данными

Что такое цифровая грамотность? Это умение понимать данные и работать с ними, анализировать, общаться с другими, обосновывая свои решения и мнения при помощи цифр. Просто понимать и анализировать информацию уже недостаточно – необходимо уметь обосновывать свое мнение, делать выводы на основе результатов анализа информации. Таким образом, подобное умение является языком современной компании, как умение читать и писать, как умение работать с компьютером. Очень важно обладать критическим мышлением, задавать вопросы «Почему?» и «А это точно так?», уметь искать ответы и подтверждения цифр и выкладок. Надо, чтобы сотрудники умели работать с информацией, потому что мы живем в информационном мире, в котором каждый должен знать, как быстро преобразовать цифры в идеи и действия, и это касается не только высшего руководства или менеджеров среднего звена, а всех сотрудников компании.

Разумеется, не каждый должен быть специалистом по работе с данными (Data Scientist), но в современном мире каждый должен уметь работать с данными грамотно. И это является важной частью аналитической культуры, без которой не построить ту самую «компанию, управляемую на основе данных».

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

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

«ПОРА ЧТО-ТО МЕНЯТЬ!»

А зачастую до этого не так просто дойти: компания развивается и приносит прибыль – кажется, все нормально. Да, может быть, можно было бы и лучше, но и текущий результат удовлетворяет руководство компании. Это потому, что нет объективной картины, нет тех инструментов, которые могут показать действительность и реальное положение дел, и когда такие инструменты появляются – это и служит тем самым триггером преобразований, которыми давно нужно было давно заняться.

Кейс 13. Одна из крупнейших аптечных сетей

В этом проекте источником преобразований стал департамент информационных технологий (ДИТ). Хотя в обязанности ИТ-отдела обычно не входят инициативы по преобразованию компании, но в этом случае отдел выполнял большое количество работы по построению отчетности («перекрашиванию кнопочек»), которая отвлекала их от выполнения основных задач. И вот коллеги из ИТ-департамента стали искать решения, которые позволяли бы бизнес-пользователям самостоятельно формировать отчетность, и вышли на нас. Однако руководство поначалу сопротивлялось. «У нас уже есть система BI, – говорили они. – Зачем нам тратить деньги на новый продукт, отчеты нас вполне устраивают!» В итоге еле-еле договорились на пилотный проект, который был выполнен силами ИТ-команды. Ну как можно доказать эффективность BI-системы? Склеить данные из разных систем, посмотреть транзакции, загрузить чеки и посмотреть средний чек, движение по чекам, отклонение от среднего чека. И вдруг на этом этапе мы получили странный результат: количество чеков в первые и последние часы работы магазина резко снижалось. Стали смотреть внимательнее и вдруг выявили «детскую болезнь ритейла» – несвоевременное открытие и раннее закрытие торговых точек из-за низкого контроля работы линейного персонала. Сотрудники магазинов открывали торговые точки в среднем на 20 минут позже, а Z-отчет приходил за 25 минут до окончания рабочего дня. Понятно, что если касса закрыта – она больше не откроется. Стали разбираться дальше и нашли аномальные потери чеков в середине рабочего дня. Подготовили соответствующий дашборд и отправили его генеральному директору. Мы не знали финансовых потерь, но посчитали, что компания потеряла 13,7 % рабочего времени за последний месяц, или 412 рабочих смен. Первый вопрос руководства был «КАК???». ИТ-команда скромно промолчала («Вы же говорили, что система BI уже есть»). Стали разбираться, запуская SQL-запросы (язык структурированных запросов), чтобы сравнить значения из нашей системы и из учетных систем, показали методологию, с помощью которой получили эти цифры. Когда показатели подтвердились, руководитель был очень огорчен и расстроен: на собрании он заявил о потере почти 15 % рабочего времени. Всех территориальных руководителей обязали контролировать доверенные им аптеки и ежедневно их проверяли: в 10 часов утра всем территориальным управляющим приходила информация по времени работы за предыдущий день, а в 12 часов управляющие должны были отчитаться, почему были допущены нарушения. Конечно, были и форс-мажорные обстоятельства, такие как отсутствие электричества, но таких причин было очень мало. Уже в следующем месяце количество нарушений снизилось до 6 %, потом до 5 %, 4 %, 3 % и достигло статистической погрешности – все понимали, что даже за минутное нарушение придется отчитываться. Проект получил продолжение – система стала отслеживать нагрузку на кассы. И тут было выявлено три интересных момента.

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

2. Система автоматически отслеживает нагрузку на кассы и при ее росте рекомендует поставить еще одну кассу. Не надо писать докладные записки и объяснять возросшую нагрузку на персонал – теперь все делается автоматически.

3. Это работает и в другую сторону: система говорит, что нагрузка снизилась и можно вместо трех касс оставлять всего две. Подобная ситуация – предмет отдельного расследования: надо выяснить, почему произошло падение. Самая вероятная причина – неподалеку открыл аптеку конкурент. Тогда вместо аптеки премиум-бренда ставится дискаунтер, задача которого – не принести прибыль компании, а выжечь каленым железом конкурентов в радиусе четырехсот метров. Как только задача выполнена, конкурент закрылся и выручка выросла, дискаунтер закрывается и на его место снова возвращается аптека премиум-класса.

Следующий проект – продажа сопутствующих комплементарных товаров. Дело в том, что аптека имеет большой и сложный ассортимент, а фармацевтов и провизоров обучают продавать комплементарные товары. Если вы купили антибиотик, вам обязаны предложить противогрибковое средство и, например, пробиотики: «А возьмите вот это средство, а то у вас животик будет болеть». Как выяснилось, многие сотрудники забывали предлагать такие комплементарные товары – анализ чеков показал, что подобные продажи были всего у 1,5 % от всех чеков. Но у некоторых сотрудников такие продажи доходили до 7 %! В итоге была перестроена система мотивации персонала, и те фармацевты, которые умели продавать комплементарные товары, стали получать дополнительные премиальные выплаты, причем на следующий же день. Это потребовало выполнения отдельного проекта по перезаключению договоров с персоналом и по работе с банком, но дало положительный эффект: люди стали подражать более удачливым сотрудникам. Они стали хвастаться: «Ой, а мне вчера деньги пришли! Пишут, что хорошо продаю комплементарные товары!» Скоро продажи этих товаров увеличились до 3 %, потом до 4 %, а потом и до 5 %. Была полностью пересмотрена система мотивации персонала. Во-первых, нельзя штрафовать – отношение к этому очень негативное. Зато можно депремировать – лишить ежедневной или еженедельной части премии, если, например, торговая точка была открыта несвоевременно. Персоналу стали доплачивать за самую большую выручку, за скорость обслуживания, конверсию и умение продавать сопутствующие товары. При этом просматривался не один чек, а несколько чеков подряд на совпадение. Да, человек мог прийти и сказать: «Нет, я это покупать не буду, в списке этого нет». Потом звонил, например, супруге и в итоге покупал товар у того, кто его порекомендовал. Да, могла сложиться ситуация, когда один человек пришел за анальгином, а второй – за аскорбинкой, это все равно считали за комплементарную продажу: лучше чуть ошибиться в сторону персонала, ведь и покупатель мог купить не у того, кто посоветовал, а в свободной кассе. В итоге была выстроена сбалансированная система мотивации персонала, что позволило выявлять и поощрять самых лучших сотрудников. Да, они получали суммарно на 20 % больше, но компания сосредоточилась именно на таких толковых сотрудниках. Дело в том, что в обучение провизоров и фармацевтов вкладываются большие средства – новые промо, новые препараты, что с чем продавать… Если сотрудник работает медленно и не умеет продавать то, что просит компания, он получает среднюю зарплату, а если перейдет к конкуренту – его и не жалко. А хорошего, толкового сотрудника нужно поощрять. Это хороший дополнительный стимул для удержания сотрудника в компании. Да, возможно, он несколько дороже, но и приносит компании куда больше денег.

Глава 21. Зрелость компании

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

Первая – централизованный подход. Все запросы идут в службу информационных технологий (ИТ), которая отвечает за данные и отчетность. Плюс в том, что ИТ-служба старается отвечать за качество данных. Огромный минус, что у этой службы совсем другие задачи: если упадет сеть, или в нее проникнет вирус, или пропадет почта и не будет резервной копии, или ляжет фронтальная система – ИТ-специалиста или даже руководителя могут уволить. А если отчета не будет вовремя, ну ничего, ждите – ИТ-отдел воспринимает это как дополнительную нагрузку, а не свою основную обязанность: главное, чтобы в бухгалтерии 1С работала, принтер печатал, почта ходила и сервера не падали. Я знаю случаи, когда бизнес ждет отчеты по несколько месяцев, а при этом ИТ считает данную ситуацию вполне себе нормальной, даже не представляя что можно организовать самообслуживание и дать возможность сотрудникам моментально получать необходимую информацию. В лучшем случае – в ИТ-отделе формируется аналитический отдел или даже отдел по работе с данными, но тогда он сам становится узким местом – ну не может один отдел удовлетворить информационный голод современной компании. Например, в компании АО «ТВЭЛ» за предоставление данных отвечал отдел в 40 человек, которые делали бесконечные выгрузки по множеству запросов и не могли сосредоточиться на задаче внедрения систем бизнес-аналитики – «нет времени точить топор, надо рубить лес».

Когда время ожидания отчетов возрастает, компания переходит ко второй стадии – децентрализованному подходу, когда каждый отдел начинает готовить свою отчетность. В итоге в некоторых департаментах компании появляются свои аналитические отделы со множеством Excel и даже подпольными базами данных! Здесь самое страшное в том, что в каждом отделе считают показатели по-своему. Количество отчетов растет, поддерживать их все сложнее. Уходят люди, которые обладали «сокровенными знаниями», как сделать тот или иной отчет. Иногда даже можно услышать: «Вбивай цифры в эту графу, а бери из этой. Как получилось – не спрашивай!» Электронная таблица пересылается из отдела в отдел, в нее вносятся изменения, а следовательно, и ошибки. Наступает «Excel-анархия» – каждый со своим отчетом. Потом выкладки из Excel переносятся в Power Point и презентуются руководителям. Дирекция долго пытается соотнести цифры одного отдела с другим или просто спрашивает: «А почему получилось такое значение?» И начинается аврал и суета, так как действительно непонятно, как так получилось. В итоге руководство обращается к аналитику, он приходит за сведениями в отдел, который занимается разработкой хранилища, и начинается долгая, кропотливая работа по поиску необходимых данных: как они попали в хранилище, как были преобразованы и т. д. Путь показателей от источников к хранилищу долог и тернист:

1. Сначала цифры должны появиться в исходных системах. Желательно, чтобы уже на этом этапе данные были чистые. Более того, извлечь сведения из ряда систем – очень нетривиальная задача, так как они хранятся не напрямую – вот заказы, вот продажи, – а в довольно сложном виде, зачастую прямой доступ к этим системам запрещен, и выгрузка значений из них официально возможна только средствами самой системы, что затрудняет их извлечение или сильно снижает скорость их получения.

2. Теперь данные необходимо загрузить. Сначала в промежуточную область – буферную зону, или Staging Area. Обычно на этом этапе не подразумевается никаких преобразований со значениями, его цель – как можно скорее забрать цифры, все целиком или дельту по новым, измененным или удаленным данным с источника для его последующей разборки или перегрузки в хранилище. После перегрузки данных они удаляются из буферной зоны. Хранить их можно только краткий период, например, для «разбора полетов», для доказательств, что именно такие сведения были взяты из источника, если там они были скорректированы. Да, и именно отсюда бизнес-данные обычно выгружаются в специальную область хранения оперативных данных (ODS). Для выполнения подобной задачи существует ряд специализированных инструментов для извлечения, преобразования и передачи данных ETL (extract, transform, load), или ETL-инструментарий (последний как раз удобнее в этом случае).

3. Потом данные из буферной зоны уже попадают непосредственно в хранилище данных, где хранятся в виде жесткой структуры. Они чистятся, преобразуются, проходят проверку на правила, сопоставляются с мастер-справочниками и «склеиваются» с уже загруженными данными – обогащаются. Цель хранилища данных, DWH (Data WareHouse), – это долговременное хранение информации в едином формате, в определенной модели. Для целей забора и преобразования цифр также используется один из основных процессов – ETL-инструментарий, а для хранения показаний – специализированные хранилища или базы данных, на которых формируется еще одна зона хранения исторических данных (HDS). Имейте в виду, что внесение новых полей требует внимания архитектора DWH для модификации модели, чтобы все цифры были аккуратно обработаны и загружены и хранилище корректно их хранило и выдавало по запросу.

4. Хранилище приспособлено для хранения данных, но не очень хорошо – для их выдачи по запросу. Для этого данные надо скомпоновать и выгрузить или в «витрины данных», или в специализированную систему, такую как хранилище аналитических данных (ADWH). Кстати, известные многим «кубы», или OLAP-технология, как раз и представляют собой частный случай подобного ADWH-хранилища.

5. После того как данные были переданы в хранилище ADWH и обработаны – сжаты, агрегированы в разрезе измерений, рассчитаны подытоги для ускорения скорости работы, – их можно увидеть с помощью BI-инструментария. Даже всем известная программа Excel имеет инструменты работы с «кубами», но в мире есть множество и специализированных инструментов.

Таким образом, от запроса на новые сведения до того момента, как они попали в инструмент бизнес-аналитики, может пройти несколько месяцев. К сожалению, до 80 % трудозатрат как раз приходится на проброску показателей между различными системами. Да и 80 % ошибок также приходится на эти этапы. Имейте в виду, что не просто загрузка новых значений, но и аудит текущих также потребует времени, чтобы понять, не произошло ли где-нибудь ошибки. В итоге период от запроса до получения информации может занимать несколько месяцев – это как раз и отражает средняя цифра в 6,3 недели в указанном выше исследовании. Разумеется, чтобы сократить время, многие отделы делают собственные выборки и ведут собственные базы и Excel, но итог один: отсутствие единой картины, Excel-анархия и бесконечные вопросы: «А почему такая цифра?» Но и это еще не все.