КИС’кин дом
Сага о корпоративных информационных системах и их пользователях
Книги читают для того, чтобы постичь высшие принципы, а высшие принципы постигают,
чтобы применить их к жизни. Если впитывают прочитанное, не вникая в суть, доходят
до такой тупости,что причиняют вред другим людям.
Цзи Юнь. Заметки из хижины “Великое в малом”
Михаил Головко
Том 2. Часть 9
Корпоративная разработка ИС - основа корпоративной системы
Многие руководители подразделений АСУ заказчика допускают грубейшую ошибку, полагая, что корпоративная разработка - удел подрядчика. Объясняют они это тем, что объем работ, связанный с проектом КИС, большой и очевидный, сроки и финансы - определены. Развитие КИС - наоборот, перспектива отдаленная, сроки отсутствуют, а о финансах в нашей российской действительности вообще нет смысла говорить.
Если же попытаться соотнести объемы работ по созданию системы и работ по ее последующей доработке и развитию, то станет очевидно, что последние сильно зависят от первых. Более того, чем хуже поставлены проектные работы, тем больше проблем возникает на этапе сопровождения и развития системы. Отсутствие промышленной технологии создания программных комплексов у подрядчиков позволяет говорить о том, что для большинства корпоративных предприятий затраты на КИС будут сильно смещены в сторону развития, а общая стоимость эксплуатации и развития КИС намного превысит расчетную.
Нередка для российских условий и ситуация, когда проект КИС (или крупная ее подсистема) по ряду причин усекается. Это всегда приводит к тому, что необходимость последующей доработки системы резко возрастает. Но кто это будет делать: подрядчик или заказчик? Что выгоднее? Может ли заказчик собственными силами доработать систему до приемлемого уровня, если с проектом зачастую даже подрядчик не справляется?
Еще одна ошибка заказчика - это нежелание (или неумение) оценить уровень корпоративной разработки подрядчика. Хотя справедливости ради следует заметить, что, как правило, сам подрядчик тоже не спешит показать методологию и технологию корпоративной разработки (чаще всего из-за ее отсутствия).
К тому же одно из малопонятных мест в корпоративных системах - оценка сложности КИС и ее характеристик, а также сложности и характеристик всех работ, с нею связанных.
Опустив вопросы финансирования доработки и развития системы, рассмотрим причины, устранение которых позволит компенсировать отклонения от проекта и облегчить эксплуатацию и развитие КИС.
Для начала приведу (в собственном изложении) несколько важных определений и соображений.
Метрика качества. Система измерения качественных показателей КИС, методологии и технологии ее создания, эксплуатации и развития. Для многих качественных показателей трудно найти подходящую метрику. Но даже в этой ситуации должен быть специалист-метролог, который занимался бы вопросами метрологии и стимулировал развитие качества и работ, и самой КИС.
Размерность информационной технологии. С точки зрения корпоративного разработчика, это:
- число уровней прикладных сервисов и API;
- число объектов и функций, предоставляемых каждым уровнем (особенно это касается прикладных уровней);
- число основных алгоритмов использования каждого высокоуровневого сервиса;
- сложность использования (программирования) - число шагов для создания целевой системы/модуля, а также инструкций и ограничений по использованию системы программирования;
- размерность подсистемы диагностики и контроля за программной реализацией технологии;
- число спецификаций, описывающих технологию, ее использование и сопровождение, логическая полнота спецификаций и прозрачность для понимания.
Определить метрику размерности технологии предоставляю читателям самостоятельно.
Сложные технологии. Технологии с большой размерностью (например, SAP R/3). Для кого-то сложным будет Oracle, для кого-то - комбинация нескольких технологий или их интеграция. Сложные технологии могут не устраивать заказчика по стоимости создания/внедрения/эксплуатации/поддержки/развития; по срокам создания/внедрения; по степени реорганизации предприятия; по другим критериям. Так или иначе, использовать сложные технологии приходится. Основная проблема здесь - оценка, оптимизация и упрощение их изучения и использования. Задача значительно облегчается при определении соответствующей метрики.
Логическая целостность КИС. Соответствие размещения, использования и сопровождения бизнес-целевых, информационных и программных объектов, элементов и функций предписанным правилам.
Адекватная программная реализация. Реализация системы в соответствии со спецификациями информационной и программной архитектуры.
Целостность проектных решений. Показатели, отслеживающие:
- соответствие технических, временных и финансовых частей проекта;
- соответствие вносимых заказчиком изменений технологической и методологической дисциплине поставщика;
- изменения договорных отношений сторон.
Неграмотная эксплуатация КИС и ее причины
Неграмотная эксплуатация КИС приводит к непроизводительной работе пользователей, быстрому исчерпанию ресурсов системы и частым обращениям к сотрудникам подразделений АСУ (при этом нормальный режим работы просто исчезает, а эти сотрудники незаметно превращаются в “мальчиков на побегушках”). Организовать нормальную доработку КИС при ограниченных человеческих ресурсах подразделений АСУ становится крайне сложно.
Основными причинами неграмотной эксплуатации являются плохо разработанная методология эксплуатации КИС (или ее полное отсутствие) и слабо проработанные требования к качеству данных:
- отсутствие соглашений (или их игнорирование) по именованию информационных объектов (например, документов). Такая, на первый взгляд, “мелочь” приводит к появлению множества местных и даже персональных “диалектов” на одном информационном пространстве, что затрудняет взаимопонимание не только между пользователями КИС, но и между разработчиками. В результате поиск информации резко затягивается, а пользователи перегружают систему непроизводительными запросами (особенно это характерно для системы документооборота и распределенных баз данных);
- отсутствие спецификаций по логической организации данных предприятия;
- отсутствие спецификаций по логической организации, размещению и конфигурированию собственных объектов КИС (программы, библиотеки, файлы конфигурации и т. д.);
- отсутствие спецификаций по срокам хранения, размещению и архивированию информации. Если КИС не имеет подсистемы управления архивами или специализированных хранилищ данных, нехватка памяти корпоративной сети и поиск информации станут постоянной головной болью пользователей и администраторов сети. При этом резко возрастает вероятность потери актуальных данных в результате проводимых ревизий памяти;
- отсутствие регламента (или его невыполнение) проверки целостности и качества данных. Нарушения целостности данных и собственных программных объектов КИС неизбежны. Более того, многие нарушения могут быть выявлены слишком поздно, когда восстановление из архивной копии оказывается уже неприемлемым или невозможным. Лучшее средство от серьезных последствий таких ситуаций - раннее обнаружение (профилактика);
- халатное отношение к выявлению и регистрации потенциально узких мест в защите, конфигурировании и администрировании КИС. Защита, конфигурирование и администрирование КИС - процесс вечный, итерационный и весьма специфичный. Опыт, приобретаемый при решении этих задач, имеет огромное значение при возникновении внештатных ситуаций. И почти всегда этим опытом владеют один-два человека, решивших ту или иную конкретную проблему. Искусство руководителя заключается в том, чтобы этот опыт стал доступен другим специалистам, по крайней мере, не был утерян по той или иной причине;
- слабая эксплуатационная дисциплина (нежелание работать по документации). “Срочно надо+”, “нам некогда+”, “мы забыли+” - эти обычные аргументы пользователей КИС и начальников их подразделений не должны ослаблять бдительность руководителей подразделений АСУ. Особенно это касается регламентов по обеспечению конфиденциальности и защиты как данных, так и самой системы.
В завершение раздела следует подчеркнуть, что некоторый недостаток прикладной и эксплуатационной функциональности можно и нужно компенсировать административными и организационными предписаниями.
Развитие КИС: корпоративная разработка неизбежна
Крупные предприятия всегда нуждаются в многочисленных программных улучшениях и изменениях КИС. В большинстве случаев эти задачи приходится решать силами заказчика (к подрядчику не набегаешься, да и обойдется это дорого). Так или иначе, доработка системы неизбежна. Весь вопрос в том, будет ли это “тяп-ляп мастерская” или хорошо продуманная и организованная корпоративная команда. При неграмотной организации работ программные изменения, вносимые в систему специалистами заказчика, носят произвольный характер. Это приводит к потере концептуальной и логической целостности КИС. Система при этом становится жестко связанной (монолитной). Каждое последующее нововведение, затрагивающее несколько программных объектов, реализуется все с большим трудом и нередко вводит новые эксплуатационные ограничения. Результат - вносимых изменений становится все меньше и в итоге они приобретают незначительный, “косметический” характер.
На что же следует обратить внимание заказчику (как, впрочем, и подрядчику) при организации корпоративной разработки?
Требования к документации - отправная точка для корпоративной разработки!
Игнорируя этот важнейший аспект, заказчик заведомо обрекает себя, во-первых, в лучшем случае на огромные потери времени и средств, во-вторых, на провал проекта вообще и, в-третьих, на значительное сокращение жизненного цикла КИС. Следует различать эксплуатационную документацию, проектную документацию и документацию по сопровождению и развитию КИС. Последняя нередко подменяется проектной, что, вообще говоря, неверно.
Основные качества эксплуатационной документации: логическая полнота, удобство представления и использования. Недостатки эксплуатационной документации сравнительно легко устранить (чем частенько приходится заниматься программистам), дописав/переписав соответствующие инструкции. При этом следует обратить особое внимание на то, что эксплуатационная документация, как правило, не содержит методологии и рекомендаций по эксплуатации КИС (см. предыдущий раздел).
Грамотно созданная проектная документация, прежде всего, полно описывает информационную и программную архитектуру и программно-техническую реализацию.
Документация по сопровождению и развитию КИС, в дополнение к документации проектной, содержит технологический, методологический и организационный базис по корпоративной разработке. Фактически, это правила изменения рабочей системы, которые нередко могут охватывать почти все стадии начального проекта, только в меньших масштабах.
Корпоративные стандарты
В дополнение к аргументам, приведенным в моей предыдущей статье (см. PC Week/RE, № 21/98, с. 43), подчеркну еще один момент.
В. Липаев в обзоре (см. PC Week/RE, № 24/98, с. 34), посвященном стандартам, совершенно прав, говоря об отсутствии системного (корпоративного) подхода к разработке отечественных ИС. Но выбор и адаптация стандартов, применяемых в информационных системах, создает проблем не меньше, чем проектирование и реализация КИС. Много ли у нас специалистов-практиков в области стандартизации? И откуда взяться перспективе, если необходимость стандартизации до сих пор не осознана ни руководством фирм-разработчиков заказных ИС, ни высшим руководством АСУ корпораций?
Важнейшая особенность корпоративных стандартов - их оптимальность. Проблемная и технологическая направленность корпоративных стандартов позволяет оптимизировать большинство архитектурных и программных решений.
Требования к корпоративным разработчикам
Работа по спецификациям - вот что отличает корпоративного разработчика от любого другого. К сожалению, здесь мы сильно отстали от Запада. Отсюда и произвольность программных реализаций отечественных КИС, и откровенное игнорирование связанных с этим проблем. При подборе персонала отдавайте предпочтение специалистам, умеющим создавать спецификации и работать по ним (по крайней мере, специалистам, стремящимся к этому).
Корпоративная работа внутри предприятия
Существуют три необходимых условия, которые следует уяснить заказчику при организации корпоративной разработки.
Первое - четкое разделение работ между специалистами АСУ. Недопустимо, чтобы функции разработки и поддержки конечных пользователей осуществлял один и тот же специалист (что является общепринятой практикой на предприятиях).
Второе - наличие и выполнение регламента по взаимоотношениям подразделений АСУ с конечными пользователями, которые дергают специалистов АСУ, когда им вздумается. Программисты - не “мальчики на побегушках”, и не ремонтная бригада по вызову.
Третье - тишина и возможность сосредоточиться. Один мой знакомый, попав на работу в американскую софтверную фирму, рассказывал, как он был поражен тем, что это условие выполняется там неукоснительно. Зайти в комнату разработчиков кому-либо из посторонних можно только с разрешения начальника отдела! Исключения не делаются даже для жен разработчиков!
Корпоративная работа с поставщиком
Одна из серьезнейших проблем, с которой постоянно приходится сталкиваться, заключается в следующем. Заказчик формирует функциональные требования к системе (которые обычно оформляются в виде технических требований или технического задания). Поставщик на основе ТЗ делает бизнес-описание системы, согласует его с заказчиком и+ приступает к созданию ИС. Постановка задачи при этом носит сугубо функциональный характер. Требования к информационной архитектуре и ее программной реализации не формализуются и фактически отсутствуют (заказчик не требует, а подрядчику это на руку). Такое сокращение производственного цикла приводит к совершенно произвольному использованию целевых программных средств, непредсказуемому качеству конечного продукта и его эксплуатационных характеристик.
Отсюда следуют два вывода:
- заказчик и подрядчик должны говорить между собой на одном языке - языке спецификаций;
- каждая программная реализация любой подсистемы КИС должна предваряться созданием хотя бы высокоуровневых структурных схем и спецификаций, согласованных с заказчиком.
Постановка задачи и описание целевой бизнес-системы
Развитие КИС предполагает два главных направления: модификация программных средств и добавление/изменение бизнес-процессов. При частых изменениях бизнес-процессов целесообразно переложить их описание и сопровождение на специалистов заказчика. Переход к работе при помощи CASE-средств здесь совершенно очевиден и неизбежен.
Оптимизация информационной и программной архитектур
(стремление сбалансировать сложность архитектурных решений и инструментальных средств)
Это настоящий клондайк для руководителей корпораций и архитекторов КИС, ибо в мире потери от неэффективного создания, эксплуатации и развития КИС в настоящее время невероятно велики. Оптимизация - главная точка сопряжения всех технических, финансовых, временных и прочих требований к проекту, которая определяет не только технологичность и эффективность КИС, но и успех или неудачу всего проекта. Одна из главных причин провалов многих проектов - несвоевременность оптимизации, которую часто откладывают на потом или вообще игнорируют. Максимальный же эффект от оптимизации достигается на этапе проектирования системы.
Небольшая иллюстрация. Число и длительность операций по сборке/разборке машины определяются не принципиальными новшествами инструментов, а продуманностью конструкции машины и технологичностью всех ее узлов и деталей. Переделать же машину после ее выпуска в свет можно лишь в мелочах.
Разработка информационной и программной архитектур
Отсутствие специалистов по профессиональному проектированию информационных и программных архитектур - это общая беда российских разработчиков и заказчиков. До сих пор мне не известно ни одной коммерческой фирмы в России, которая бы профессионально занималась исключительно проектированием ИС. Есть фирмы, профессионально занимающиеся постановкой задач, а вот фирм-проектировщиков нет. Если у поставщика и есть отдельное подразделение, занимающееся проектированием, то только для своей фирмы. В России стало нормой, что поставщики решений предлагают собственную программную реализацию задачи. Неудивительно, что спецификации и стандарты, предлагаемые ими, сильно ориентированы на собственную технологию, методологию и конкретные инструментальные средства, т. е. составлены весьма субъективно, а их качество оставляет желать лучшего.
Унификация программных средств КИС
Унификация программных средств КИС сильно упрощается при наличии информационной и программной архитектур. Программные средства КИС всегда носят модульный (компонентный) характер, и унификация достигается, прежде всего, стандартизацией интерфейсов модулей (хочешь или нет, а спецификации интерфейсов приходится писать). Можно, конечно, писать спецификации на систему и по мере необходимости, но результатом будет бессвязный пакет спецификаций, разобраться в котором будет крайне сложно.
Здоровый консерватизм в выборе программно-технических средств
Недопустимо гоняться за новшествами информационных технологий, в первую очередь программных, которые меняются с ошеломляющей скоростью! В настоящее время для реализации подавляющего большинства КИС нужны не новшества, а высокое качество программных продуктов и возможность их интеграции. Не должно быть технологий ради технологий. Важен не инструмент сам по себе, а временные и финансовые показатели его использования. Время ориентации на конкретные инструментальные средства с точки зрения их возможностей прошло - наступило время интерфейсов и инкапсуляции языковых средств.
Эффективность системы защиты
Ни для кого не секрет, что ИС - наиболее уязвимая часть предприятия. Обстоятельства могут потребовать, чтобы система защиты КИС была полностью реализована силами заказчика. Систему с оригинальной программной реализацией несравненно труднее изучить и взломать, чем тиражируемую. Промышленный шпионаж и несанкционированное влияние на ИС растут буквально на глазах, и очень скоро эффективность системы защиты ИС (в том числе способность к модификации) будет одним из главных ее качеств.
Простота реализации диалоговой среды пользователя и легкость в эксплуатации
Здесь специалисты заказчика дадут сто очков вперед поставщику - тот, кто знает, чего стоит обучить пользователей операционной логике приложений, всегда предпочтет сделать хороший интерфейс. Поставщики же страдают “болезнью инструментального интерфейса” - их диалоговые среды больше похожи на инструментальные, а не целевые средства работы.
Говоря о корпоративной разработке, нельзя не упомянуть еще об одном существенном моменте. Заказчик имеет огромный, постоянно пополняющийся опыт в сфере контроля и управления операционной и эксплуатационной логикой программных средств КИС. Использование этого опыта при проектировании системы может значительно сократить стоимость эксплуатации и развития КИС.
Подытожим
Вообще, трудно провести грань между корпоративными разработками заказчика и подрядчика. Разница, скорее всего, в масштабах проводимых работ (например, заказчику при развитии КИС надо добавить и реализовать несколько бизнес-процессов, а подрядчику - описать и реализовать всю бизнес-систему).
В погоне за развитой функциональностью системы заказчик никогда не должен забывать о средствах ее реализации. Фундаментальных операций над информацией сравнительно немного - сбор, передача, извлечение, ввод и вывод, вычисления, преобразования, представление (структуризация), размещение, хранение, настройка, администрирование, защита, контроль и диагностика.
Возвращаясь к началу статьи, хочу еще раз обратить ваше внимание на то, что усечение проекта (или расширение функциональности при начальных финансовых затратах на проект) часто происходит за счет упрощения реализации системы (снижение степени декомпозиции архитектуры, объединение модулей, объединение фундаментальных операций в одну программную функцию и пр.).
На всех этапах создания и жизненного цикла необходимо внимательно следить за тем, чтобы программная архитектура КИС и реализация фундаментальных операций не страдали от усечений проекта. Нарастить функциональность намного проще, имея хороший технологический фундамент КИС, обратное же часто невозможно.
Михаил Владимирович Головко - руководитель группы автоматизации и связи Курского филиала ООО “Межрегионгаз”. К нему можно обратиться по телефону: (0712) 56-9078 или по адресу: mic@mrg.sovtest.ru.
Том 1. Часть 1 - см. PC Week/RE, № /97, с. 59. Том 1. Часть 2 - № /97, с. 60. Том 1. Часть 3 - № /97, c. 64. Том 1. Часть 4 - № /97, c. 47. Том 1. Часть 5 - № /97, c. 50. Том 1. Часть 6 - № /97, с. 56. Том 2. Часть 1 - № /98, с. 62. Том 2. Часть 2 - № /98, с. 41. Том 2. Часть 3 - № /98, с. 47. Том 2. Часть 4 - № /98, с. 48. Том 2. Часть 5 - № /98, с. 90. Том 2. Часть 6 - № /98, с. 43. Том 2. Часть 7 - № -28/98, с. 39. Том 2. Часть 8 - № /98, с. 33.
