Проблема

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

И чем больше одновременно работающих команд, которые зависят друг от друга, тем как правило больше вероятности возникновения необходимости расследования на тему “на чьей стороне ошибка”.  Самое смешное, что ситуации, при которых можно сделать очную ставку с одновременным присутствием представителями этих команд… и ВСЕ РАВНО НЕ ДОБИТЬСЯ РЕЗУЛЬТАТА. 

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

Варианты решения

Если вы заказчик, то вылечить это можно несколькими способами.

Первый вариант возможных действий очевиден — найти исполнителя, который выполняет ВСЮ работу до результата ОТ и ДО. И сам решает внутри себя все возникающие проблемы. А у вас, как заказчика, есть простой маркер — все либо работает, как надо, либо же работа не выполнена.

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

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

Сам по себе этот вариант неплох, но он подразумевает, что вы хорошо понимаете факт необходимости управлять проектом и ваш подрядчик. При этом, вы готовы доплачивать именно за то, что работы по проекту не только реализуются, но и ведется грамотное управление. А управление любым проектом подразумевает ЕЖЕДНЕВНОЕ внимание к ходу его выполнения. Это достаточно времязатратная процедура высококвалифицированного человека.

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

Общий алгоритм решения

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

Описание кейса

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

В момент сборки, сборщик пропикивает  сборочное задание в своей системе учета и она должна ему прямо сразу распечатать правильные наклейки. Но чтобы распечатать в этот момент наклейки, предварительно должно произойти множество событий: менеджер должен был зарезервировать товар и подтвердить заказ, 1С автоматически должна отправить задание в web сервис работы с маркетплейса, что нужно этот заказ будет собран и что номер заказа такой-то. Тот, в свою очередь обращается к маректплейсу и подтверждает сборочное задание (это все автоматически) и получает этикетки. Далее он эти этикетки кладет в какую-то папку. И далее, с помощью программы синхронизации, этикетки попадают в то место, где его ищет складская программа. Именно в том формате и виде, какие должны быть… и еще вовремя.

Чтобы система работала корректно, должны работать “как часы” разные продукты:

• складская программа;
• 1С и со своими регламентными заданиями;
• web сервис, который обращается в маркетплейс;
• любой маркетплейс (а их более 25!) должен корректно отдавать информацию web сервису;
• система синхронизации, которая передает итоговые файлы в нужное место

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

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

Знакомо?

Принцип “замкнутый круг” позволяет внедрить в вашей IT системе, которая управляет этим процессом, назначить “ответственного”, который следит за тем, что все работает корректно. В случае описываемого кейса, инициатором того, что заказ подлежит обработке и сборке будет 1С — она “выдает” задание web сервису и тем самым запускает цепочку процессов, которая в итоге должна привести к тому, чтобы этикетки были доступны конечному потребителю на складе. 

Соответственно. В данной системе, необходимо назначить ответственным 1С, исходя из следующих соображений:

1С знает, что она “запустила” процесс подготовки сборки по конкретному заказу.

И именно она должна проверить ТУ САМУЮ ПАПКУ, в которой через некоторое адекватное время ДОЛЖНА появиться этикетка. 

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

Только в таком случае можно гарантировать, что этот участок будет работать таким образом, что: 

а) Есть кому разобраться в проблеме

б) Проблема будет известна обслуживающему персоналу задолго до того, как станет “пожаром”, когда сборщик просто не смог собрать заказ и он остался “наполовину собранным” — что само по себе, очень затратная ситуация

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

А вы часто сталкиваетесь с такими проблемами? Что что-то не работает, а у вашего обслуживающего персонала “работает как надо”?