Содержание
Эта серия статей — результат личного опыта автора. Не всегда это опыт позитивен, но это именно взгляд изнутри. Взгляд на одну из успешнейших мировых ERP и присущие ей особенности. Первая статья этой серии (предыдущая) опубликована в апрельском номере журнала PC Magazine на с.85-88 и доступна по адресу pcmag.ru/solutions/detail_print.php ?ID=34219&print=Y
Техническая безопасность
Она в SAP низкая. В одной схеме базы данных могут быть расположены данные сразу нескольких компаний, для различения их записей в таблицах и инфотипах существует поле MANDT (часть таблиц модуля HR — humain resources, он же HCM, humain capital management, предназначенного для управления человеческими ресурсами — называют не таблицами, а инфотипами, infotype, их записи — записями инфотипов). Соответственно таблицы и инфотипы с этим полем называются клиенто-зависимыми, а без него — клиенто-независимыми. Совокупность записей всех клиенто-зависимых таблиц и инфотипов с одинаковым значением этого поля и всех записей клиенто-независимых называется мандантом. Разграничение прав доступа на основе значения этого поля прописывается в логине. Логины для разных мандантов разные и не имеют никакого отношения к логинам СУБД. Далее, полномочия в SAP бывают обычными (хотя правильнее их назвать плоскими) и структурными (последние существуют только в модуле HR и отсутствуют в других модулях). Первые описывают режим доступа к любым элементарным объектам — процедурам, транзакциям (программам), таблицам, ракурсам, инфотипам; вторые — к под-деревьям организационного плана компании (организационный план компании состоит из «объектов» и «соединений», которые хранятся соответственно в 1000 и 1001 инфотипах).
Связь соединяет два внутренних (т.е. из модуля HR) объекта или внутренний с внешним (т.е. с объектом из другого модуля). Связи не имеют никакого отношения к foreign key баз данных, а являются, как уже было сказано, записями 1001-го инфотипа и имеют следующие атрибуты: идентификаторы двух объектов, между которыми связь протянута, направление (от первого ко второму или от второго к первому), имя связи (называемое соединением), два произвольных числа (называемых взвешиванием и приоритетом), даты начала и конца существования связи, временная привязка. Связи между совершенно разнородными парами объектов могут иметь одинаковое имя (соединение). Временная привязка — это ограничение целостности для периода существования, и бывает следующих видов: связь с данным именем и направлением между данными объектами может существовать только один раз за все время существования объектов; может существовать несколько раз, но периоды существования не пересекаются и не образовывают разрывов; только не пересекаются (возможны разрывы); никаких ограничений. Не существует временной привязки, обязывающей только не образовывать разрывов (и допускающей пересечения). Под-дерево организационного плана, на которое выдаются полномочия, задается корнем, максимальным количеством уровней и путем анализа, который является перечислением допустимых связей без указания глубины их расположения в дереве (в т.ч. без указания идентификаторов объектов, которые связь соединяет). Не получив полномочия на некоторые объекты — записи 1000-го инфотипа — невозможно по их первичному ключу найти относящиеся к ним записи других инфотипов, в которых зафиксированы те или иные свойства объектов. Пути анализа поименованы и применяются не только механизмом контроля полномочий, но и report-ами для извлечения под-деревьев.
Между плоскими и структурными полномочиями выполняется операция AND, они группируются в профили, профили в роли, роли в групповые роли. Вычитания полномочий нет. Роли и групповые роли при установленном модуле HR выдаются под-деревьям организационного плана, начинающимся с должностей, штатных должностей, рабочих мест, персон (табельный номер привязывается к логину в 105-м инфотипе) и организационных единиц компании, а без него — напрямую логинам. Под-дерево, которому выдаются полномочия, не имеет количество уровней и путь анализа в качестве ограничений. Не существует механизма не делегировать полномочия какой-либо из его ветвей.
Роли в SAP не имеют никакого отношения к ролям СУБД. И все бы хорошо, если бы не одно -но?: ни логин, ни роль не ограничивают ABAP-программы, а только поставляют им дополнительные данные: report-ы имеют доступ сразу ко всем инфотипам и таблицам, ко всем их записям (в т.ч. к записям всех мандантов) и сразу по всем операциям (вставка, удаление, изменение, чтение). Существует транзакция SCI для выявления потенциально опасных действий программы до ее запуска, но после запуска проконтролировать и остановить программу не может ничто. Потенциально в системе есть место для двух центров контроля — в ABAP-интерпретаторе и в SQL-интерпретаторе. Однако в первый возможности контроля до сих пор не добавлены, а во втором они отключены — СУБД низведена просто до раздатчика и приемщика записей. А что вы хотите? ABAP появился на пятилетку раньше, чем Clipper и Fox.. Чтобы соответствовать современным представлениям в язык добавили операторы обращения к базе данных, однако есть серьезное подозрение, что SAP никто не переписывал. Вы наверное представляете, что такое Fox, обращающийся за данными в Oracle или Postgres (опять же, чтобы соответствовать современным представлениям в SAP добавлен Java, однако весь продукт наработан на ABAP, и уйти от него невозможно).
Замусоривание базы данных — вещь обычная. Взять хоть тот же пример из предыдущей статьи: запустите транзакцию PB40, выберите в ней любое мероприятие, нажмите «выполнить» (F8), пройдите несколько экранов, введя в них данных (переход от экрана к экрану осуществляется по кнопке «сохранить», Ctrl-S), выйдите из транзакции (кнопка «выход», Shift-F3) на каком-нибудь промежуточном этапе (не доходя до последнего экрана). Вы оставили после себя в базе данных столько записей инфотипов, сколько экранов прошли, rollback не было, замусоривание базы данных произошло. А теперь представьте, что у вас будет с информационной безопасностью, когда один и тот же кандидат будет внесен в базу данных несколько раз под разными номерами — и использован под ними, когда будет выполняться удаление дубликатов (а также как упадет производительность персонала, рыскающего по длинному списку, как он будет демотивирован этим и т.д.)
Смежным моментом является копирование данных из ранее использовавшейся АСУ в SAP. Фирма SAP утверждает, что существует однозначное соответствие между таблицами/инфотипами, демонстрируемыми в транзакциях, и таблицами реляционной базы данных — и категорически запрещает копировать в базу данных напрямую в обход SAP (выключил constraint-ы, загрузил в таблицы, включил constraint-ы). Мол дескать SAP сделает за вас проверку данных на самосогласованность, которая и так уже существует в предыдущей АСУ. В самом SAP загрузка делается транзакцией LSMW или группой методов «download» на ABAP (возможна загрузка в ракурс). В этом случае вы, правда, напарываетесь на неюзабельность — соответствие полей загружаемых данных и полей таблиц/инфотипов задается не во внешнем файле (например, текстовом или xml-ом, которые можно было бы сгенерировать и подправлять автоматически), а в самой транзакции вручную. Не будем уже упоминать такие мелочи как поле «текст неограниченной длины», которое может быть только одно в таблице и только последнее из полей, и пр. Меньше универсальности, больше перекраивания, больше ошибок.
Экономическая безопасность
Экономически выгоднее привести бизнес-процессы компании в соответствие с возможностями SAP, предоставляемыми настройками (checkbox-ами и radiobox-ами в настроечных транзакциях), чем добавлять функциональность своими разработками на ABAP. Новая функциональность незнакома саперам-настройщикам; конфликтует с service pack-ами (ведь у принимаемого на работу абапера на лбу не написано, может ли он писать так, чтобы разработки с ними не конфликтовали, да и квалифицированный абапер иногда такого наворотит; для модуля HR вместо появления новых версий будут поставляться расширения EhP и CLC, конфликты с которыми скорее всего тоже войдут в практику), в результате конфликтов разработки придется переписывать или не устанавливать service pack-и (а теперь, видимо, и расширения); документация на разработки будет скудна, в связи с чем сопровождать их будет крайне тяжело. В случае SAP все это становится критичным в связи с высокой ценой саперов — уже невозможно переписать все с нуля за копейки. Это же замечание ограничивает в возможностях re-engineering-а вообще, затрудняя перепроектирование организации в произвольном направлении.
Модель ведения бизнеса, предоставляемая SAP, отнюдь не лучшая. Опять сошлемся на уже упомянутый пример. Часть инфотипов предназначена для хранения данных о кандидате в сотрудники (в кандидаты принимают в транзакции PB40), часть — для хранения данных о сотруднике (в сотрудники принимают в транзакции PA40). Первые инфотипы являются подмножеством вторых. Может статься, вам нужно собирать больше данных о кандидате, например, регистрировать его инвалидность и ее параметры. Однако инфотип, в который они записываются — инфотип 4 — предназначен только для сотрудников. Если вы пропишите его для мероприятия транзакции PB40, то система продемонстрирует его в мероприятии, но введенные данные не сохранит. Записи инфотипов для кандидатов хранятся в таблицах базы данных с именами вида PBxxxx, где xxxx — номер инфотипа, номера меньшие тысячи содержат лидирующие нули; записи инфотипов для сотрудников — в таблицах с именами вида Paxxxx; инфотипы демонстрируются и сохраняются ABAP-модулями MPxxxx00. Независимо от того, в какой таблице вы хотите регистрировать инвалидность и ее параметры — в PA0004, во вновь созданной PB0004 (создав ее, вы вторгаетесь в область системных имен и рискуете нарушить работу системы при установке ближайшего service pack), или во вновь созданной таблице вне системных имен, вам придется модифицировать MP000400. Кроме того, придется решать проблему переноса данных при приеме сотрудника из числа кандидатов. Полные перечни инфотипов для кандидатов и инфотипов для сотрудников вы можете видеть в транзакциях PB30 и PA30. Если вам необходимо поэкспериментировать с приемом кандидата или сотрудника: удаляют кандидата или сотрудника со всеми записями инфотипов в транзакциях PB30 и PA30 соответственно, выбирая в меню клиента, а не в меню экрана, позиции -Вспомогательные функции / Удалить номер кандидата- в первой транзакции и -Утилиты / Удалить табельный номер- во второй (некоторые элементы управления программы появляются не в ее окне, а в меню клиента посреди его собственных элементов управления: не знаешь — не догадаешься).
Даже при всем изменении бизнесадля согласования модели его работы с моделью SAP, вопреки рекламным заявлениям, что использование продукта нуждается только в настройке, но не в доработках, производимых покупателем, все внедрения (разве что только за исключением Rollout — случая покупки одним потребителем у другого всех настроек со всеми разработками и установки их у себя «под копирку». Но практически всегда модели бизнеса потребителей достаточно отличаются) требуют добавления полей в инфотипы, создания непредусмотренных отчетов и просто дописывания логики работы — это вы знаете и по другим АСУ. Т.е. даже если вы поступитесь, без разработок все равно не получается.
Кроме того, в современном обществе настройка превратилась фактически в обманку: каждый производитель преднамеренно создает в своем ПО область ручной путанной работы — а как иначе превратить клиента в дойную корову? Иначе клиент скопирует ПО, уйдет и не заплатит. От программирования такая настройка отличается уже мало. Сошлюсь на книгу С. Г. Кара-Мурза «Манипуляция сознанием», которую можно скачать с сайта kara-murza.ru, она же продается в московских магазинах (в других городах, думаю, тоже есть). Вопрос «дойки» тесно смыкается с вопросом «удержания», см. en.wikipedia.org/wiki/Vendor_lock-in Чтобы развеять ваш романтизм, расскажу о более циничных способах, например в хартии w3.org прямо записано, что новая технология не может быть стандартизирована, если существует технология с той же областью применимости — при изложении HTML60 мне разъяснили, что этот пункт направлен не против аналогичных технологий, а против более совершенных (речь в частности шла о том, что появление языка JavaScript надолго остановило развитие языка HTML). Мы по наивности воспринимаем (по крайней мере бессознательно) международные организации как созданные пользователями и для пользователей, на самом деле скинулись парни с деньгами. ДажеW3C. От кого и что вы еще ожидаете? От R/3?
Не только настройщиков, но и пользователей нужно учить. Стереотипы использования, положенные в основу SAP, отнюдь не современны, например, не нажать-на-кнопку, а нажать-на-кнопку и на-кнопку-«выполнить» (F8, иконка «часы»). Например, для запуска мероприятий в той же транзакции PB40 вы нажимаете на кнопку напротив мероприятия (она утопляется, нажатие на другую освобождает первую кнопку, т.е. они ведут себя как radiobox-ы, при этом о том, что это кнопки, нужно еще догадаться, их ряд замаскирован под левую утолщенную границу таблицы, строки которой содержать названия мероприятий), а затем на иконку «часы». Экраны перегружены элементами управления: переход к следующему экрану — кнопки «сохранить», «следующий экран»; возврат к предыдущему экрану — кнопки «назад», «предыдущая запись»; выход из транзакции — кнопки «выход», «отмена». Вместо многострочных текстовых полей ввода («textarea» в терминах HTML) система содержит несколько однострочных («text» в терминах HTML), приходится делить строку на несколько частей и вбивать части в отдельные поля. Длинные выпадающие списки («select» — «option» в терминах HTML) демонстрируются не с места ранее выбранной позиции, а с самого начала. Часть автоматизируемой работы попросту приходится делать вручную, например, после ввода нового кандидата (сотрудника и т.д.) он не появляется автоматически на экране в списке кандидатов, для обновления этого списка нужно выполнить поиск всех кандидатов вручную. А главное — сам интерфейс сделан так, что последовательность событий не прогнозируема, опытный пользователь, который в другом ПО разбирается сам, тут бессилен. Таким образом дороги не только изменения настроек и доработок, но и смена собственного персонала. И расходы состоят не только из оплаты обучения. Время на привыкание к такому ПО увеличивается — даже если допустить отсутствие негативной реакции и сопротивления. А негативная реакция есть.
Для миража, устроенного SAP в масштабах планеты, я знаю только один аналог: отбирание срубленного и неоплаченного леса, и внушение, что это — ваши леса, снесение домов, построенных без оплаты земли, и внушение, что это — ваша земля. И так во всех цивилизациях. Больше ничто с SAP по грандиозности миража сравниться не может.
SAP украшает имидж организации, позволяет не беспокоиться за мысли отружающих, что ты принял правильное решение. SAP — это что-то очень крутое?
Мотивы выбора лица, принимающего решения, могут быть сильно чреваты для жизнеспособности организации. Приносить ей и техническое, и финансовое кровопускание. А в целом по отрасли цены снизиться не могут, в ряду конкурентов видим типичную диссипативную структуру, типичный триггерный эффект: кто больше отобрал, тот больше имеет ресурсов для ведения войны, а значит с позиции силы снова больше отберет. Конформизм является механизмом поддержания триггерного эффекта — против постоянного вдалбливания человеческая природа бессильна. Доли рынка конкурентов стоят в геометрической прогрессии, а все они барражируют, закрывая новые подходы. Поэтому делегирование права принятия решения вниз IT-шникам или бизнес-аналитикам приводит не более чем к нахождению мелких отличий, много меньших масштаба самой отрицательной величины. Чтобы избежать кровопускания, необходимо подняться над схваткой (см. например «Свои представления вместо чужих, путь первый: схема экрана есть схема данных» kv.by/index2008494201.htm и другие статьи), ведь давно известно из науковедения (science of science), что новая точка роста, скачек возникает при создании нового типа инструмента, а не следующего изделия старыми инструментами. Почитайте хотя бы классика Eugene Garfield
Казалось бы саперы должны быть благодарны фирме SAP за то, что она создает клиентам проблемы и позволяет им заработать, решая эти проблемы. Однако не надо забывать, что после подавления конкурентов и загаживания «окружающей среды» так, чтобы никто больше не мог разместиться в той же нише, цены падают так, что плата у «плюща» только соответствует прежней в индустрии (но не превышает).
Юридическая безопасность
Никакое ПО не может заставить операции клиента соответствовать требованиям законодательства. Хоть отслеживай производитель ПО национальное законодательство, хоть не отслеживай. С другой стороны, схему бизнес-процессов организации, подписанную проектировщиком, или альбом бланков приказов, подписанный юристом, можно ввести в любую АСУ. А вот приезды и замеры, какие компоненты установлены и каково количество операций в течение суток вам совершенно ни к чему.
За саповские деньги вы реализуете любое решение. И в те же сроки — все организации плохо управляются, но никто в этом не признается.
Автор: Тюрин Дмитрий
главный специалист департамента ЦАБС «АСБ Беларусбанк»,
член группы внедрения SAP R/3 HR
Источник: Полный текст читайте на сайте PC Magazine/RE
