Что такое бизнес процесс в программировании

Привет! Меня зовут Андрей и я являюсь тимлидом команды разработки роботизированных процессов в компании Talan Systems.

Технология RPA (Robotic Process Automation) является одной из форм автоматизации бизнес-процессов, основанная на метафорическом программном обеспечении «роботов».

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

То есть запрограммированный «робот» использует UI, как и обычный пользователь, только во много раз быстрее.

В этой статье я хочу познакомить читателя с технологией, которая может обеспечить быстрый старт карьеры в прогрессивной области IT, для того, кто решит постигнуть её, как разработчик.

О чем же пойдет речь?

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

«Робот» в данном случае — не что-то физическое, а ПО, которое может быть запущено на любом ПК, не требуя предварительной интеграции с многочисленными системами. Это достигается путем того, что для интеграции с любой системой вам достаточно будет понимать, как процессы данной системы выполняются пользователем, а после этого записать данные действия в виде алгоритма в одной из программ для автоматизации (RPA).

RPA не нуждается в дополнительных API поскольку работает с пользовательским интерфейсом программы, как человек.

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

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

Activity в одной из программ для создания роботизированных процессов RPA — UIPath

На скриншоте выше выставлена цепочка последовательностей, которая показывает «роботу», что он должен:

1. Нажать на кнопку.
2. Ввести логин в форму ввода.
3. Ввести пароль в форму ввода.

Почему это возможность начать карьеру?

На данный момент интернет наполнен похожими статьями о том, что же такое RPA, в связи с чем мне не хотелось бы повторять их, а, в свою очередь, поговорить о том, как данная область может помочь вам начать карьеру в интересной и развивающейся области.

Как вы могли наблюдать на скриншоте выше, создание алгоритмов для робота не требует знаний программирования (на начальных стадиях), а лишь умение создания алгоритмов логических последовательностей, а также системный подход.

Что означает, что даже для человека, который только начинает свой путь в IT и еще не знаком с основами какого-либо языка программирования, данная технология поможет совершить отличный старт для дальнейших свершений.

17 вопросов джуну: что должен знать Junior-разработчик

Может ли быть все так просто? Отчасти

Для того чтобы начать создавать «роботов» действительно не нужно иметь углубленных знаний в программировании, в его классическом понимании (не нужно учить синтаксис языка либо изучать его устройство). Однако в процессе вашей работы над коммерческим проектом, с приобретением опыта написания алгоритмов в формате WorkFlow приходит осознание того, что можно достичь гораздо большей производительности создаваемых программных роботов, используя их в связке в программами, написанными на популярных языках программирования (таких как C#, Python, C/C++…).

Что же получается? Мы опять вернулись к тому, что нужно изучать языки программирования?

Это правда, однако давайте проанализируем, в какой ситуации находится человек, пошедший этим путём:

1. Благодаря навыкам, которые человек получил путем написания программных роботов с помощью WorkFlow, он научился понимать и создавать структуру программ, в их обобщенном виде — без использования синтаксиса конкретного языка.
2. После того, как человек понял структуру программ, на определенном этапе изучения он осознает, что в некоторых задачах, использование робота — является некоторой прослойкой, связывающей взаимодействие робота с UI-интерфейсом сервиса и вычислительную мощность программы заточенной на решение лишь одной задачи.
   Для примера: Мы пишем программного робота, который, повторяя действия пользователя (нажимает на кнопки, вводит текст), производит авторизацию на почтовом сервисе (Gmail, i.ua…), считывает все новые сообщения за сегодняшний день, формирует из текста полученных сообщений список и передает его в заранее написанную программу для NLP, которая сможет распознать структуру письма и передать данные про неё в программного робота, который визуализирует предоставленные программой данные в удобном для пользователя формате.

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

Возможности платформы роботизации вне использования программ написанных на сторонних языках программирования

Как было написано ранее:

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

Однако прошу заметить, что речь в данной ситуации идет про задачи не начальных и даже не средних уровней разработки роботизированных процессов. Сама по себе технология RPA может и выступает на сегодняшний день, самостоятельным решением огромного количества процессов (напомню, для работы с RPA вам не нужно знать языки программирования)

Все доступные категории Activity в программе UIPath

В каждой из категорий, отображенной на данном скриншоте, содержится от 5 до 20 подкатегорий с десятками Activity, так что самостоятельную функциональность технологии точно не назовешь ограниченной.

Немного цифр

Глобальный рынок RPA:

• В 2016 году объем рынка составил $271 млн.
• 100-150% составил прирост мирового объема внедрений RPA в 2017 году.
• Более 70% крупных международных компаний уже применяют технологии RPA.
• Увеличение количества поисковых запросов в 2,5 раза за 5 лет.

Темпы роста рынка RPA (прогноз до 2021 года):

К 2021 году может вырасти до $3 млрд.

Ключевые факторы роста:

• RPA-системы развиваются и адаптируются под большинство корпоративных процессов.
• Синергия RPA-систем и искусственного интеллекта позволит влиять на процессы принятия управленческих решений.

Итог

Данная технология доступна всем и имеет достаточно низкий порог вхождения, так что даже те люди, кто еще не написал в своей жизни ни одной строки кода, смогут начать работать RPA разработчиком.

Надеюсь данная статья заинтересует молодых разработчиков в данной технологии и поможет без труда окунуться в мир коммерческой IT разработки.

Источник: tproger.ru

Автоматизация бизнес-процессов продуктовой IT-компании

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

Но по факту продуктовая разработка уже давно доросла до того, чтобы в полной мере использовать BPM-решения — системы для управления бизнес-процессами. Рассказываем про примеры использования BPM.

В статье умышленно не говорим о кейсах IT-аутсорса — только про продуктовые компании. Хотя BPM подойдет и в аутсорсе, отличия в процессах будут значительные, поэтому это тема для отдельной статьи.

Не разработчиком единым живет продуктовое IT

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

— Несколько линий технической поддержки — консультируют клиентов по продукту, обрабатывают запросы об ошибках;

— Системные администраторы (dev ops) — отвечают за работу серверов и работоспособность оборудования, не всегда входят в команду разработчиков;

— Маркетологи различных специализаций: общий маркетинг, таргетинг, PR и event маркетинг и т.д. В отделе маркетинга очень много потенциальных активностей, мы даже вынесли их в отдельную статью — о бизнес-процессах маркетинга.

— Копирайтеры – пишут тексты о продукте для блога и внешних площадок по заказу маркетологов;

— Технические писатели — пишут пользовательские инструкции и материалы в справочный портал при выходе нового функционала, обновляют старые справочные статьи при изменениях существующего функционала;

Получается, что в компании может работать значительное количество сотрудников, которые непосредственно разработкой не занимаются. При этом они пользуются каждый своим софтом. Маркетинг работает в своих программах, если вообще не в экселе, поддержка в своих, копирайтеры и технические писатели становятся заложниками CMS-систем и онлайн-редакторов вроде Google Docs.

Отсутствие единой системы при постоянной итеративной разработке приводит, например, к таким ситуациям:

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

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

Правильнее всего будет по максимуму организовать бизнес-процессы ИТ-компании в единой системе и автоматизировать их. Вот тут как раз и пригодится BPM-система с возможностями проектного управления как намного более емкий сервис для управления компанией. Мы, конечно, будем рассматривать это через призму нашего продукта Neaktor, но все описанное ниже будет актуально в целом при использовании процессного подхода к продуктовой разработке.

Бизнес-процессы IT-компании продуктового направления

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

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

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

— Учет дефектов (багов)

— Запуск нового сервера

— Покупка / аренда нового оборудования

— Учет серверов и оборудования

— Отработка тикета в тех. поддержку

— Написание статьи в блог или SMM

— Создание и обновление справочной статьи

И так далее. Список может содержать более 50 возможных бизнес-процессов, связанных непосредственно с продуктом. Из этой большой массы задач в очень многих IT-компаниях автоматизированы только 2: создание нового функционала и баг-трекинг. И, хотя ведение проекта и баг-трекинг — это одни из главных процессов в IT компании, получается, что они составляют менее 5% того, что стоит автоматизировать.

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

Взаимосвязь задач и отделов друг с другом

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

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

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

1. Когда вы разрабатываете параллельно и веб- и мобильное приложение, вы, скорее всего, ведете их в двух проектах. Но часть задач может быть актуальной для обеих версий. Это означает, что тестировщику придется не забыть продублировать тикет в оба проекта. Это можно автоматизировать так: при создании задачи вы выбираете галочку «Актуально для мобильной версии» и задача автоматом дублируется в проект по мобильной версии. Понятное дело, что «тикет для мобилки» может отличаться из-за UI, но, когда тикет уже поставлен, его всегда можно релевантно дополнить. А если вы спохватились уже после релиза, что забыли добавить какой-то функционал в мобильную версию, то это эпичный провал.
2. О больших изменениях продукта обязательно нужно писать статьи и рассказывать в рассылке. Начать писать текст, когда функционал уже вышел – это слишком поздно. Поэтому намного эффективнее будет при создании задачи заполнить атрибут «Требует поста в блог», чтобы в момент, когда задача будет взята в работу или перейдет в тестирование, автоматически поставилась задача для копирайтера на написание статьи. Притом в этой задаче будет добавлена ссылка на сам тикет, и копирайтеру не придется много переспрашивать своих коллег о том, что же это за функционал, о котором он должен написать.
3. Если в поддержке клиенту пообещали, что какой-то функционал скоро появится, то, конечно, обещание стоит выполнить. Однако если у вас тысячи клиентов, а изменение может выйти не на следующей неделе, а через полгода, то забыть про обещание довольно легко. Можно, конечно, поставить напоминание, но оно не спасет, так как объективно релизы продуктов неминуемо смещаются и редко выходят в строго запланированные даты. Зато этот кейс можно запросто автоматизировать, если отметить в тикете клиентов, которые просили узнать о выходе функции, а потом система автоматически отправит им шаблонный email о выходе функции.

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

Бонус: бэк-офис

В предыдущих разделах статьи мы специально говорили только про те бизнес-процессы, которые связаны непосредственно с разработкой продукта.

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

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

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

BPM для IT

Полноценную организацию бизнес-процессов в ИТ сложно переоценить. Мы уверены, что будущее IT-компаний за BPM.

Автор статьи

Николай Сушко

Общается со многими клиентами лично, пишет про релизы, публикует мнения и расписывает бизнес-кейсы. Всегда рад обратной связи!

Источник: neaktor.com