Работая над масштабными проектами автоматизации и создавая новые информационные системы, мы каждый раз сталкивались с необходимостью внедрения подсистемы ведения справочников, классификаторов, регистров и других подобных объектов, составляющих справочную информацию заказчика (СНИ).
Более 15 лет работы в ЛАНИТ с системами управления НСИ Жизнь подарила нам клиентов с самыми разными требованиями.
И, конечно, на этих проектах возникали разные ситуации.
Расскажу вам о нескольких поучительных историях, произошедших с нами.
В статье вы найдете примеры, которые будут полезны многим, кто занимается разработкой программного обеспечения.
Ну а для тех, кто работает напрямую с НСИ , будет еще интереснее - собственная рубашка будет ближе к телу.
Отдельное спасибо замечательному художнику за иллюстрации.
Случай первый.
Как загрузить вагон и тележку Создание единой системы управления подрядчиками для крупной производственной компании, имеющей множество заводов по всей стране и за рубежом.
Цель проекта – создать единую базу контрагентов для всех подразделений.
Управление контрагентами осуществляется на основе заявок, которым присвоен приоритет от низкого до срочного.
Срочная заявка должна быть обработана специалистами НСИ в течение 2 часов, независимо от разницы во времени между отделами.
Живая история Проект был согласован со всеми заинтересованными сторонами (в этом нас убедило руководство заказчика) и разработан в установленные сроки в соответствии с утвержденными требованиями.
Презентация созданной системы управления контрагентами прошла гладко, пока одна видная женщина - руководитель Сибирского филиала - не встала и очень энергично, используя русские идиоматические выражения, не довела до сведения собравшихся, что когда к ней под погрузку приехал железнодорожный вагон готовая продукция, она не будет ждать 2 часа, пока кто-нибудь в Москве рассмотрит заявку на добавление покупателя.
Она не будет оплачивать простой машины, пока заявка будет одобрена, а внесет данные покупателя в систему как есть и отправит товар, а московские товарищи потом смогут столько же разобраться с информацией о покупателе.
как они хотят. Это заявление поддержали еще несколько руководителей филиалов компании, что практически полностью разрушило централизованную методику ведения единого справочника контрагентов на основе заявок.
В результате проект был доработан таким образом, что все филиалы имели доступ к базе данных контрагентов и могли вносить в нее изменения напрямую, но при этом осуществлялся автоматический поиск аналогичных записей, которые отображались сотруднику филиала.Что мы помним: не верьте словам менеджеров и ответственных лиц со стороны заказчика о том, что все решения согласованы, все по теме и возражений нет. Определите всех заинтересованных сторон проекта и попытайтесь узнать системные требования и ограничения непосредственно у них.и он принял решение о необходимости корректировки данных, которые позже были проверены экспертной группой.
Случай второй.
Мы используем его, как хотим Создание централизованной системы управления клиентами страховой компании с большим количеством филиалов и агентов по всей стране.
Цель проекта – создание консолидированной клиентской базы для использования в аналитических приложениях.
База данных была собрана со всех филиалов, данные проверены, дополнены, устранены дублирующиеся объекты.
Количество клиентов в одном филиале колеблется от тысячи до нескольких миллионов.
При этом перекрытия клиентов между филиалами практически нет. Живая история После того как была создана консолидированная база данных клиентов, ее нужно было периодически сравнивать с базами филиалов на предмет различий, затем обрабатывать их и загружать изменения в консолидированную базу данных.
Прирост клиентской базы между сверками составил несколько тысяч записей.
Для выполнения сверки был создан специальный модуль, архитектура которого спроектирована исходя из того, что он должен быстро сравнивать большое количество записей и генерировать относительно небольшой XML-файл с изменениями для загрузки.
Формат XML был выбран заказчиком.
После внедрения системы мы получили от заказчика сообщение о том, что модуль сверки работает крайне медленно и генерирует для загрузки в консолидированную базу огромный файл, который они никак не могут открыть.
Что это оказалось? Заказчик осуществил первичную загрузку данных из филиалов в сводный справочник.
Экспертам эта работа показалась утомительной и трудоемкой, и они просто взяли модуль сверки и скормили ему полные данные новой ветки, которые никогда не загружались в консолидированный каталог.
Модуль сверки, который в соответствии с техническим заданием должен был формировать информацию о различиях в количестве нескольких тысяч записей, получил на вход два миллиона записей, и все они отсутствовали в сводном справочнике.
В результате после нескольких часов нечеловеческих усилий модуль сверки все же сгенерировал для скачивания файл, в который вошли все данные ветки.
И да, этот файл был огромным.
Модуль сверки не использовался заказчиком по прямому назначению, но заказчику понравился сам факт того, что сверка позволяет выполнить первоначальную загрузку данных, и он собирался продолжать работу в таком режиме, только попросил существенно ускорить работу модуль и сделать что-нибудь с созданным файлом, чтобы его можно было открыть в текстовом редакторе.
На наши возражения, что модуль сверки не предназначен для первичной загрузки данных, заказчик радостно показал технические характеристики и спросил, а где это здесь написано? Мы используем его так, как хотим!
В результате нам пришлось внести изменения в архитектуру модуля сверки для обработки больших объемов данных и формирования выходного файла в формате CSV, так как заказчик совершенно не хотел отказываться от такого удобного инструмента.Что мы помним: Всегда включайте в спецификацию описание ограничений — чего не должна делать ваша система.
Ну или создавать решения, учитывающие все возможные варианты использования, что гораздо дороже.
Случай третий.
Не слонёнок, а слонёнок, и ему тоже придётся летать Создание централизованной системы ведения основных данных финансовой организации.
Цель проекта — создание централизованной системы ведения справочников и классификаторов с распространением изменений по заинтересованным системам и базам данных.
Предоставление доступа внешних систем к каталогам через веб-сервисы нашей системы.
Обычно клиенты имеют среднее количество записей в каталоге от нескольких сотен до нескольких тысяч.
Наш недавний рекордсмен — каталог, в котором было 11 миллионов записей.
Но этот клиент преподнес нам сюрприз.
Его каталог содержал более 100 миллионов записей.
Скачивали мы его больше суток, потому что.
При первоначальной загрузке было произведено множество проверок данных.
Это не было бы большой проблемой, но заказчик потребовал, чтобы каталог загрузился в течение нескольких минут.
В результате нам пришлось сильно изменить способ работы системы с этим справочником.Что мы помним: В современном мире данных становится все больше, и темпы их роста постоянно увеличиваются.Фактически он поддерживается вне системы, а мы предоставляем лишь интерфейс для его использования.
В настоящее время мы разрабатываем новые способы работы нашей системы с очень большими каталогами.
Надеемся, заказчику понравится.
Система должна быть готова к высоким нагрузкам даже там, где они изначально не предполагались.
Мы постоянно развиваем наше решение, учитывая современные тенденции роста данных и возрастающие требования к скорости их обработки.
Случай четвертый.
Сложный трюк с файлами Создание централизованной системы ведения основных данных в крупном банке.
Цель проекта – создание централизованной системы ведения справочников и классификаторов с распространением изменений по заинтересованным системам и базам данных.
Особенностью проекта являются очень сложные процессы распространения изменений, затрагивающие множество систем.
Поскольку в дальнейшем мне придется упомянуть о нашем собственном решении по управлению справочными данными, позволю себе небольшое лирическое отступление.
Узнайте больше о системе НОРМА.
Задачи наших клиентов во многом схожи, и мы решили снизить затраты на разработку программного обеспечения и сократить сроки реализации проекта, создав собственную универсальную платформу для ведения мастер-данных и мастер-данных (Reference Data Management & Master Data Management).
Система существует уже более 10 лет, и все эти годы мы в ЛАНИТе активно ее развиваем.
NORMA поддерживает централизованное и распределенное управление справочными данными.
Все данные и метаинформация сохраняются с учетом истории изменений, а система позволяет просматривать и изменять весь массив справочных данных на произвольную дату в прошлом или будущем.
Для каталогов можно настроить процессы координации и утверждения изменений.
В состав системы входит выделенный сервер распространения изменений, который позволяет взаимодействовать с внешними системами через различные интерфейсы и создавать достаточно сложные интеграционные бизнес-процессы (своего рода мини BizTalk Server).
У нас есть пакеты экспорта/импорта данных, которые могут загружать/загружать данные каталога в базы данных и файлы различных форматов.
Поддерживается ведение таблиц преобразования для внешних систем.
NORMA включает в себя графический построитель запросов и дизайнер отчетов.
Помимо работы с собственными каталогами, система позволяет через свой интерфейс просматривать и изменять каталоги, которые расположены во внешних по отношению к ней базах данных, а также использовать эти каталоги в построителе запросов и пакетах экспорта/импорта.
В ответ на возникновение различных событий в системе, например, событий изменения каталога, могут запускаться подключаемые программные компоненты, написанные на C#, которые могут как проверять данные, так и взаимодействовать с внешними системами и, по сути, Сама система НОРМА.
Практически все функции системы доступны через веб-сервисы.
Систему можно масштабировать как по вертикали за счет увеличения мощности сервера приложений и базы данных, так и по горизонтали за счет использования многоузлового сервера приложений, в котором каждый узел или группа узлов отвечает за выполнение отдельной функции.
Для хранения справочных данных система может использовать Microsoft SQL Server, Oracle или PostgreSQL. Обычно при создании ссылок и процессах распространения изменений заказчик консультируется с нашими аналитиками о том, какой инструмент или набор инструментов, предоставляемых системой, лучше всего использовать для конкретной задачи.
В этот раз заказчик сказал, что каталоги и процессы будет создавать самостоятельно.
Через некоторое время к нам обратился один из специалистов заказчика с жалобой на то, что его данные не загружаются в систему.
В качестве подтверждения нам был отправлен пакет импорта данных, исходный файл с загружаемыми записями и сообщение об ошибке о том, что загружаемые данные имеют неверный тип.
Давайте начнём разбираться.
Мы крутим пакет так и сяк, пробуем разные варианты представления исходных данных, но повторить ошибку не можем.
Обращаемся к заказчику с вопросами: может быть в пакете импорта подключены программные компоненты, может на каталог наложены какие-то дополнительные ограничения, может данные не из этого процесса? На все получаем ответ - ничего такого нет, все должно раньше легко загружаться и работать.
Оказывается, этот импортный пакет был лишь верхушкой айсберга.
Если кратко и сильно упрощенно, то произошло следующее.
Процедура импорта загрузила в каталог правильные данные из исходного файла.
Исходный файл был удален.
Затем наша система распространила изменения на несколько баз данных, одна из которых сравнила свои собственные данные с нашими изменениями и создала файл несоответствий, который был возвращен в нашу систему для загрузки.
При этом для скачивания этого файла заказчик использовал ту же процедуру импорта, что и для исходного файла.
И именно этот файл, сгенерированный внешней системой, содержал данные не того типа.
Очевидно, что при анализе исходного файла мы не смогли обнаружить никаких ошибок, а о втором файле и разросшемся процессе распространения изменений нам ничего не сказали.
Что мы помним: Всегда проверяйте получаемую информацию, даже если вам говорят, что у нас здесь небольшая проблема, и она именно в этом месте, клянусь мамой! Проанализируйте проблему в контексте.
Случай пятый.
Я привык к несоответствиям Создание системы управления мастер-данными в производственной компании.
Цель проекта – создание системы ведения справочной информации в управляющей компании, имеющей множество филиалов, заводов и конструкторских подразделений.
На этот раз мы не продвинулись дальше нескольких презентаций.
Технарям очень понравилась наша система НОРМА.
Она осветила все их существующие проблемы.
Потом пришла очередь показать систему руководству, и тут случился облом десятилетия.
Высокопоставленный руководитель посмотрел, послушал и сказал: «Мы все здесь работаем над продукцией Apple, у них есть определенный стиль, а ваша система в этот стиль не вписывается.
Мы даже не будем об этом думать».
Что мы помним: Клиенты разные, и некоторым вы просто не подходите.
Стиль другой.
Подобные истории случаются в разных проектах.
Что было интересного в вашей проектной жизни? Какой урок стал для вас неожиданным? Поделитесь в комментариях.
Кстати, мы ищем специалистов в нашу команду.
Теги: #Управление разработкой #Управление проектами #Управление продуктами #Анализ и проектирование систем #ланит
-
Программа Лояльности
19 Oct, 24 -
Честные Логотипы
19 Oct, 24 -
Чемпионат По Системному Программированию
19 Oct, 24
