Взять готовое решение или создать свое — что лучше для оптимизации бизнес-процессов? Опыт внедрения Enterprise-проекта

Привет! Я — Наталия Федосеева — Business Analyst в NIX c 2015 года. Три года занимаюсь Enterprise-проектами, два года как Lead. Хочу поделиться тем, как наша команда внедрила и настроила Enterprise-систему и в чем польза таких приложений.

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

Что такое Enterprise-приложение

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

Рынок Enterprise-решений сформировался из основных нужд компаний:

  • CRM (Customer relationship management) — приложение, которое знает все о клиентах;
  • EAM (Enterprise asset management) — управление обслуживанием физических активов организации;
  • BPM (Business process management) — визуализация и автоматизация процессов;
  • ERP (Enterprise Resource Planning) — отслеживание бизнес-ресурсов, планирование бюджетов, объемов сырья и производственной мощности, управление статусами бизнес-обязательств перед клиентами;
  • HRM (Human Resource Management) — поиск, найм, обучение и развитие сотрудников;
  • KM (Knowledge management) — базы знаний, вся ценная информация, должностные инструкции и документация разработок;
  • BI (Business intelligence) — аналитика данных, статистики, отчеты, инсайты.

Рынок Enterprise-приложений

Несмотря на обширный выбор, огромная доля рынка остается в категории «Другое». Готовые решения по разным причинам одним компаниям не подходят вовсе, а для других удовлетворяют потребности лишь частично. Все смотрят в сторону трендов Enterprise. Если ваша команда тоже хочет сделать такой проект, выясните несколько моментов.

Чувствую, без Enterprise не справиться...

Перед внедрением любого новшества я рекомендую обратить внимание на:

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

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

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

Стоимость покупки. Цена полного комплекта программного обеспечения для крупной компании достигает сотен тысяч и даже миллионов долларов. Сейчас Enterprise-системы доступны для малого и среднего бизнеса. Тарифный план можно выбрать в зависимости от количества сотрудников, модулей, уровня кастомизации, формата хранения данных (облачный сервис или on-premise решение). Стоит отметить, что часто стоимость внедрения решения превышает стоимость покупки.

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

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

Безопасность. Более безопасными позиционируются облачные решения. У них уже профессионально организована работа с серверами как со стороны hardware, так и со стороны software. Тем не менее, если компания может позволить себе on-premise решения и готова самостоятельно следить за безопасностью, она может быть более спокойна за сохранность своих данных.

В NIX — гибридная система внутренних решений. Относительно несложные бизнес-процессы мы автоматизируем с помощью готовых on-premise систем. Как мы к этому пришли?

Эволюция Enterprise-решений в NIX

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

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

Специалист контролирует все потребности NIX. Например, так произошло с бизнес-процессом букинга комнат для переговоров. Изначально бронирование было «на коленке», потом инициативная команда девелоперов разработала функциональное приложение. На момент релиза это было отличное улучшение. Но основной флоу бронирования комнаты был не совсем удобным, и бронь занимала много времени. Позже сделали новое приложение с другими технологиями, которое уже стало частью Enterprise-системы.

Многие налаженные процессы продолжают успешно функционировать и приносить свои плоды, а некоторые еще в процессе становления. Старые решения постепенно отмирают и трансформируются в связи с новыми запросами и возможностями автоматизации. Таким же образом по мере изменения процессов выстраиваются и способы их автоматизации.

От сырой идеи до авторского решения

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

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

Вызовы в Enterprise-решениях

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

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

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

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

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

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

Оповещения об изменениях высылаем на почту целевой аудитории и передаем новость через лидов. Параллельно обновляем ссылки во всех инструкциях и готовим гайды для пользователей. Документ нужно писать простым языком, чтобы на поиск ответа ушло минимум времени. У нас лучше всего прижились гайды в формате FAQ для несложных процессов и видеозаписи с пошаговой инструкцией для более масштабных.

Внедрение новых процессов

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

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

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

Автоматизация бизнес-процессов и их изменение

Работа бизнес-аналитика прямо или косвенно влияет на бизнес-процессы в компании. Порой стейкхолдеры, выполняя задачи в рамках своей зоны ответственности, не обращают внимание на целостную картинку, работают «по инерции». Когда бизнес-аналитик выстраивает общее видение процессов, могут всплывать какие-то несоответствия. Их следует устранить или минимизировать.

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

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

Так что же лучше: приложение или старая добрая Excel-таблица? Правильного ответа нет. На разных этапах развития у компаний свои потребности. Одни из них закроют готовые Enterprise-решения, для других понадобятся специальные разработки. А может, вовсе не нужно изобретать велосипед и с задачей справится вездесущий Google Spreadsheets. Критично относитесь к идеям, учитывайте финансовые возможности организации и, конечно, автоматизируйте все, что имеет смысл автоматизировать.

Похожие статьи:
[Материал опубликован в рамках конкурса статей на DOU] Technical writer. Он же documentation developer. Он же технический писатель. Он же инженер отдела...
Привет, DOU! Я Денис, бизнес-аналитик IT-компании Artjoker, поделюсь с вами мыслями о том, какие есть виды бизнес-аналитиков и что нужно...
  Одна из самых известных компаний по разработке жестких дисков и технического оборудования для сборки и работы с серверами...
Мы начинаем подводить итоги 2016 года на ДОУ. Посмотрим, как выглядит рынок труда в этом году и как он изменился по сравнению...
29-річний киянин Олег Берестовий має освіту інженера-електроніка. Він був одним з наймолодших депутатів в Україні, відкрив...
Яндекс.Метрика