Просто о сложном. Надежная технология из не очень надежных модулей

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

Штирлиц шел по цветочной улице, а Плейшнеры все падали и падали из раскрытых окон…

Очень многие компании в своем развитии проходят по одной дороге. Начиная с 70-х годов прошлого века, значительная часть информационных проектов строилась на идее «все в одном». Поколение 50+ может многое рассказать свои детям и внукам об АСУ и АРМ-ах. Чем обычно заканчивались попытки создания единой программы, в которой работают все. Разные зоны ответственности диктуют совершенно различные требования, часто противоречащие друг другу.

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

Ушли в прошлое АСУ и АРМ-ы, прошла мода на «большие ERP», которые решают все вопросы учета и управления», все больше и больше видна тенденция отказа от попыток «все в 1С». Долго еще будут идти ожесточенные споры между сторонниками «одной программы» (не важно SAP или 1С) и фанатами модульного подхода и системной интеграции разнородного ПО. Продавцы софта и разработчики всех мастей будут вешать лапшу на уши руководителям разных компаний с обещаниями, что наша программа подойдет вам идеально.

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

Почему мы используем разные программы

• Специализированная система позволяет эффективнее организовать операционную работу. Там, где в «универсальной программе» на участок потребуется 3-4 человека, при использовании специализированного ПО достаточно 1-2 сотрудников. Уменьшение операционных расходов быстро превысит любую разницу в стоимости лицензии. Нет смысла приобретать программу дешевле на 50 тысяч, если нам придется дополнительно нанимать сотрудника с окладом 25 тысяч ежемесячно.
• Специализированное ПО гораздо легче адаптировать под постоянно меняющиеся условия бизнеса. Если изменение/доработка/настройка в небольшой программе будут реализованы за 3-4 рабочих дня, то советующий проект в «Единой Системе» потребует несколько месяцев и стоит в десятки раз дороже
• Модульность обеспечивает большую производительность и устойчивость работы. Если возникнут проблемы с каким-то модулем, при грамотно организованной системной интеграции работа компании не остановится. В самом плохом случае задержка составит пару часов. При сбоях большой системы велик риск остановки всей технологии на дни, если не на недели и месяцы
• Масштабируемость. Мы можем модифицировать каждый модуль, добавлять/изменять не останавливая технологический процесс.

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

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

Краткий ответ – можем при грамотно организованной технологии. Есть такая партия.

Приведем живой пример из практики

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

Можно ли отказаться от CRM? А где фиксировать предварительные контакты с потенциальными покупателями, как разбирать воронку продаж, анализировать контракты от первых договоренностей до согласования условий и окончательного подписания документов?

Где будем создавать и контролировать производственные планы? Когда и какой материал надо взять со склада или купить у поставщика. Сколько дней понадобится на производство? Достаточно ли наших мощностей, какой будет загрузка станков и оборудования? Каких подрядчиков привлечь, чтобы обеспечить выполнение всех наших обязательств по планируемому, но еще не заключенному контракту? Как доставить готовую продукцию покупателю?

Какие задания дать исполнителям?

• Как проконтролировать текущий статус и сроки выполнения этих задач?
• Оценить загрузку персонала и рассчитать диаграмму Ганта?
• Как свести в одну цепочку все финансовые ресурсы от сделки с покупателем до всех необходимых производственных расходов?
• Как собрать все заявки, оценить их обоснованность и согласовать с планами централизованных служб?
• А грамотно организовать процесс бюджетирования на год и более?

В конце концов, после всех этих задач необходимо правильно оформит все документы, провести операции в 1С рассчитать налоги и свести бухгалтерский баланс.

Интеграция этих участков – довольно непростая – задача, отметим только некоторые, самые очевидные потоки данных.

• Новые контракты появляются в CRM. Пока идет согласование условий и предмета договора, эти сделки не должны быть в других учетных системах
• Когда мы договорились с покупателем. Вероятность подписания контракта велика. Необходимо запустить процесс производственного планирования. Оценить, что нам потребуется для выполнения своих обязательств. Сделка должна появиться в системе производственного планирования и согласования. Но в других системах, ERP, MSP, тем более в 1С этих договоров быть не должно – контракт еще не подписан, юридических обязательств нет
• Окончательно согласованы все условия и детали договора. Контракт поступил в работу. Необходимо делать заказы поставщикам и подрядчикам, формировать задачи исполнителям. Договор должен появиться в ERP и MSP. Бухгалтерия не видит контракт – нет ни отгрузки, ни оплат.
• Пошла фактическая работа – отгрузка покупателю, поступления денег. Конечно, в этой стадии договор должен быть в справочнике 1С.

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

Первый месяц технология работала «как часы». Через полтора начались проблемы. Сначала пошли жалобы – сделки из CRM попадали в систему производственного планирования не на следующий день, а иногда через 2-3 дня. Возник скандал, когда уже подписанный договор не попал ни в систему планирования, не прошел визирование. Даже в 1С пришлось добавлять этот контракт вручную. Проблемы возникали неожиданно в непредсказуемое время. Иногда две три недели проходили без происшествий, иногда, как назло, неприятности случались перед ответственными совещаниями или подготовки бюджета. Не выдержав регулярных скандалов, уволился руководитель, ушли три ключевых программиста, на которых были завязаны многие процессы…

Разбор полетов выявил основные причины неприятностей

Процедуры обмена данными работали по расписанию – в 2 часа ночи:

• иногда проходил разрыв соединения, выгрузка из CRM падала, таблицы;
• для импорта формировались не до конца, часть новых договоров «пропадала»;
• в некоторых случаях загрузка прерывалась автоматически загружаемыми обновлениями операционной системы;
• ряд процессов блокировался антивирусом;
• при регламентных работах, в тч при планируемой ночью перезагрузке сервера, не всегда запускались служебные программы, обеспечивающие автоматический обмен данных.

Почему аналогичные проекты в других компаниях не набивали подобные шишки и не наступали на такие грабли?

Главное, что приводит к подобным ошибкам, неправильное понимание зон ответственности со стороны IT-руководителя. Необходимо четко определить, что разработчики отвечают за конечный результат, а не свое представление о том, как нужно правильно программировать. Десяткам пользователей главное – быть уверенным, что список договоров актуальный и корректный. И, если возникают вопросы к данным, то важно создать технологию, максимально гарантирующую нужный результат, а не ссылаться на объективные трудности, типа обновления антивируса или банальной нехватки оперативной памяти и дискового пространства.

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

• «Слона едят по частям» — любая процедура обработки данных состоит из отдельных кусочков (модулей или блоков).
• Все эти блоки должны быть выстроены в единый сценарий работы. Системные процедуры ведут лог, фиксирующий начало запуска каждого модуля, успешность его работы и время окончания.
• Необходимо предусмотреть варианты различных действий системы, в случае если какой-то модуль не поставил отметку об успешном завершении своей работы. Например, в случае обрыва связи, стоит предусмотреть повторный запуск процедуры через полчаса-час. Если системе не удается автоматически разрулить ситуацию, интерфейсы восстанавливаются из последней успешной выгрузки, а администратору посылается оповещение. В идеале администратор должен отслеживать все такие оповещения за час-два до начала рабочего дня, чтобы иметь возможность исправить ситуацию к 10 утра.
• Дополнительно рекомендуется поставить проверку на «контрольные суммы», хотя бы количество договоров. Менеджеры не любят сюрпризов. Если сегодня список договоров резко увеличился (более, чем на 15-20%) или уменьшился в разы, есть все основания считать, что произошел технический или операционный сбой. Такой случай система должна квалифицировать как ошибку и восстанавливать данные из последней успешной выгрузки.

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

Автор: Дмитрий Корнилин