Бизнес и системный анализ в крупных проектах

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

Клиенты:

1. Компании с большими финансовыми и временными затратами на разработку
2. Компании, которые хотят направить работу IT на увеличение прибыли
3. Компании, внедряющие новые бизнес-модели

Зачастую бизнес получает от ИТ-разработчиков совсем не то, что он ожидал. Типовой ответ - так было написано в ТЗ, при этом не умышленные пробелы исполнитель трактует так понял. Сам документ часто очень детально описывает требования к системе без соотнесения с реально протекающими процессами, не показывая как будут работать люди и почему нельзя обеспечить тот же бизнес-результат проще и быстрее.

В реальности планирование, исполнение и контроль одного процесса удобнее и быстрее сделать при помощи комбинации ИТ систем, но сфокусированное на разработку одного ПО техническое задание не проявляет полноты ИТ поддержку всего процесса, что приводит к проблемам.

Ориентируясь на ТЗ, в котором не проявлено соотнесение с целями заказчика, протекающими реальными процессами, разработчики создают ПО при внедрении которого вдруг обнаруживаются проблемы этих несоответствий. Иногда несоответствия велики настолько, что внедрение созданного решения требуют еще одного решения. Часто необходимость полноценной поддержки процессов при внедрении влечет непредсказуемую массу доработок, что делает процесс внедрения неуправляемым. Так же решаемые методом “костылей” быстрые доделки и переделки создают "технологический долг", который со временем начинает серьезно тормозит развитие систем и бизнеса, вплоть до того, что исправление ошибок составляет до 80% всех проводимых работ

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

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

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

Результаты для бизнеса:

• Сокращение time to market, сокращение времени окупаемости изменений
• Скорость получения нужного результата с опорой на аналогичный опыт
• Предсказуемость и управляемость IT развития

Типовые шаги процесса:

Успешный старт начинается с трех компонент

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

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

В случае изменения процесса обслуживания клиента, в фокус ставится клиент, его цели, боли (pains) и радости (gains), после чего разбираются сценарии достижения целей, проводится аудит удобства достижения этих целей. Web-аналитика и UX-аудит позволяют найти скрытые проблемы и оценить их значимость.

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

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

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

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

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

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

Как выглядит сценарий, на примере авторизации на сайте через email:

(Системный) Авторизоваться на сайте для доступа в личный кабинет. – (уровень моря)

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

Уровень: цель пользователя

Основное действующее лицо: клиент (посетитель нашего интернет-магазина)

Участники и интересы:

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

Предусловия: посетитель должен быть не авторизован

Минимальные гарантии: посетитель узнает факт успешной или неуспешной попытки авторизации

Гарантии успеха: посетитель авторизован

Триггер: посетитель сайта запускает сценарий авторизации

Основной сценарий:

1. Клиент запускает авторизацию
2. Система подтверждает, не авторизован ли уже клиент и количество неуспешных попыток авторизации
3. Система считает количество попыток авторизации
4. Система отображает клиенту форму авторизации
5. Клиент вводит email и пароль
6. Система подтверждает наличие клиента с таким email в системе и совпадение пароля и не превышенность количества попыток входа в данный аккаунт
7. Система авторизует клиента, добавляет историю просмотра и корзину данного сеанса с последним сеансом этого аккаунта клиента
8. Система отображает сообщение успешности авторизации и переходит на шаг сценария, из которого клиент прервался на авторизацию с отображением персональных данных на страницах

Расширения:

1. Система уведомляет клиента о факте осуществленной ранее авторизации и предлагает либо прервать сценарий, либо перейти к шагу 4, при этом если шаг 6 успешно пройден, то 7 шаг выполняется с уточнением:
2. Система деакторизует клиента под старым аккаунтом, авторизует клиента под новым аккаунтом, при этом история просмотра и корзина данного сеанса взаимодействия остается в старом аккаунте, в новый не переходит далее
3. Количество попыток авторизации с этого ip превысило порог Х за последние Y минут:
4. Переход к шагу 4, на форме авторизации дополнительно отображается капча
5. Система подтверждает корректный ввод капчи
6. Капча введена неправильно:
7. Система увеличивает счетчик неуспешных попыток авторизации и под данный аккаунт
8. Система отображает сообщение о неуспешности и возвращается к шагу 2
9. Аккаунта с данным email не обнаружено.
10. Система показывает сообщение о неуспешности и переходит к шагу 2
11. Пароль от аккаунта с данным email не совпадает с введенным
12. Система увеличивает счетчик неуспешных попыток входа в данный аккаунт
13. Система отображает сообщение о неуспешности и предлагает на выбор, либо переход к сценарию Восстановление пароля либо переход к шагу 2
14. Счетчик попыток входа в данный аккаунт за последние Y минут превысил Х раз
15. Система отображает сообщение о блокировке входа в аккаунт в течении Y минут и переходит к шагу 2

Список изменений в технологии и данных:

• Использование капчи
• Вспомогательная информация отсутствует

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

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

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

Доработки сайта и внутренних систем требуют проектирования интерфейса. Непротиворечивые use case, проверенные на отсутствие частых исключений, схемы и структуры данных дают отличную возможность сделать прототипы дизайна. В процессе прототипирования происходит свертывание (trimming) для достижения лучшего соотношения цена-качество.

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

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

Приемка разработанного результата создает положительную обратную связь, позволяя аналитикам расти и совершенствоваться.

Штатные аналитики-эксперты в AWG имеют 15 летний опыт работы на разных ролях в развитии крупного бизнеса.