Глава 10. Пять принципов хорошего решения

Хорошее решение — какое оно?

Прежде чем создать хорошее решение нужно понять, хорошее — это какое?

Пять принципов хорошего решения

1. Решает проблему заказчика

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

• Проблема либо создаёт убытки;
• Либо сокращает доходы.

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

«Зачем знать первичную проблему, если кто-то уже нашёл решение и спустился на уровень задач?» — спросите вы. Чтобы выбрать оптимальный путь решения задачи, который приведёт к достижению цели.

Оптимальный — приносящий максимальную пользу за минимальный бюджет.

Рассмотрим пример задачи: автоматизировать основной бизнес-процесс предприятия.

Выясняем, какая цель за этим стоит. Уточняем, зачем нужна автоматизация. Чтобы сократить время обработки клиентской заявки и повысить стабильность обработки. Чтобы повысить конкурентоспособность и снизить себестоимость обработки.

Уточняем, что именно сейчас мешает добиться этой цели:

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

2. Отвечает критериям качества заказчика

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

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

Критериями могут быть:

• Скорость отклика системы не более 1 секунды;
• Доступность системы 24/7 99,7% времени.

3. Хорошо документировано

Документации достаточно для:

• Использования — инструкции по ролям;
• Администрирования — инструкция администратора;
• Поддержки и адаптации — описание решения, из каких компонентов оно состоит, как они взаимосвязаны и какие точки расширения в него заложены;
• Быстрого ввода нового человека на любую из ролей.

4. Просто поддерживается

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

В хорошем решении есть:

1. «Хлебные крошки» — при возникновении ошибки в системе есть возможность быстро понять её причину.
2. «Модульность» — функционал декомпозирован на отдельные блоки, что позволяет переиспользовать одни и те же функции в разных частях системы. Это даёт возможность внести изменения в одном месте, а они применятся везде, где используется этот модуль.

Например, в решении реализована интеграция с 1С, в которой передаётся информация о контрагенте из 1С в ELMA365, а о договорах контрагента из ELMA365 в 1С. Для прозрачности интеграционного взаимодействия необходимо хранить информацию о:

1. Времени взаимодействия — в какое время началась и закончилась передача данных;
2. Направлении взаимодействия — откуда и куда был отправлен запрос;
3. Субъекте и параметрах взаимодействия — что именно было в интеграционном запросе. Например, загрузка данных о контрагенте.

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

• Время взаимодействия — это время запуска и завершения экземпляра процесса;
• Направления взаимодействия — это название экземпляра процесса или самого процесса.

А для сохранения информации о параметрах взаимодействия потребуется сохранять информацию в контексте процесса.

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

• Вносить изменения в одном месте;
• Видеть историю запросов в одном месте.

5. Легко адаптируется

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

• На этапе проектирования подумать о возможной расширяемости;
• Хорошая документация решения;
• Его модульность.