Sunday, January 27, 2008

Знакомьтесь, это - SAP BW, OLTP-система (проект РЖД №1: ЧТО)

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

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

На данный момент, у меня в голове находится концепция серии заметок, когда каждая из них будет отвечать на один из вопросов "ЧТО автоматизировалось", "КАК шло внедрение", "ПОЧЕМУ оно так шло" и "как было БЫ, если бы внедрение шло по-другому".

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

Итак, к первому ЧТО.

Задачка такая. РЖД. Вагоны регулярно отправляются в рейсы. Есть некий набор станций, на которых происходит передача вагонов от одной организации к другой. При передаче для каждого вагона составляется документ, в котором фиксируется номер вагона, а также дата и время его передачи. Каждая организация, и сдающая, и принимающая, составляет свой такой документ. В целом, организаций в процесс вовлечено много, и вагон в каждом рейсе может несколько раз передаваться между ними. А потом возникает вопрос, кто сколько должен РЖД за пользование вагоном. Плата рассчитывается на основе времени пробега. В установленные сроки все организации отсылают свои документы за прошедший отчетный период (месяц) в одно из расчетных подразделений РЖД, где и производится начисление. Технически документы организации за один отчетный период попадают в РЖД в электронном виде, грубо говоря, как массив данных вида вагон-период-дата-время.

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

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

И вторая особенность. Все хорошо, когда в течение рейса вагона у нас есть данные о всех его отрезках. Вагон непрерывно сдается-принимается между организациями. Организации иногда "шалят" со временем, но мы умело и планомерно эти вопросы разрешаем. Проблемы начинаются, когда вагон вообще "выпадает" из рейса. Ну, например, данные о нем просто забыли прислать. Или умышленно хотят не платить - авось, не заметят. Или время сдачи "уехало" так далеко, что стало похоже, что вагон и не ездил здесь вообще. Нам, сидя в теплом московском офисе среди бумаг, не видно, куда делся вагон со станции, и надо установить это по документам. Таких ситуаций тоже возникает приличное количество. Поэтому и тут разработаны правила, как искать "пропавший" вагон. (Уже чувствуете? Тут есть слово "искать".) Сначала надо попробовать найти вагон по определенным признакам, "отмотав назад" время на несколько месяцев, потом попробовать найти в других массивах, "перемотав вперед" на несколько месяцев. (Здесь видно, что для поиска требуется некий перебор с программной логикой.)

Что же хотел заказчик от автоматизации? До внедрения несколько целых подразделений занимались перелопачиванием поистине гигантских объемов информации. За каждым компьютером сидел человек с двумя окнами Microsoft® Excel, в каждом из которых было открыто по массиву данных, и глазами искал "несходки". Иногда надо свериться с распечаткой, иногда - залезть в специализированную информационную систему РЖД. Хотелось, чтобы была создана система, умеющая формировать отчеты, в которые бы попадали "подозрительные" вагоны. Далее бы пользователи их бегло проверяли, возможно, удаляли бы из них "несправедливо оклеветанные" вагоны, и отправляли ли бы список прямиком виноватой организации. Те, в свою очередь, должны либо согласиться с претензиями (акцептовать), либо обосновать отказ от претензий, либо предложить свой вариант правды.

Информация об акцептах должна была бы быть записана обратно в нашу систему, а отчеты, в которых раньше "вылезали" "подозрительные" вагоны, должны были бы стать пустыми. (Здесь тоже обратите внимание: необходима корректировка данных, причем данных самого детального уровня - уровня вагона.) Пустой отчет - значит, в отчетном периоде все ОК. Иначе говоря, нет вагона - нет проблемы.

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

Читайте продолжение в следующем посте. Там я расскажу КАК было проведено внедрение.

1 comment:

Daniyar said...

Ясно! Коротко! Доходчиво! Ждем новых постов!