?

Log in

No account? Create an account
ГОСТы серии 34 устарели?! Ну извините!! - Экономика, управление, ИТ, системы, анализ
December 26th, 2013
11:17 pm

[Link]

Previous Entry Share Next Entry
ГОСТы серии 34 устарели?! Ну извините!!
Моя карма на эту осень была в том, чтобы снова несколько раз столкнуться с утверждением о том, что ГОСТ серии 34 устарел. И ладно бы в "кухонном" обсуждении в фейсбучной группе по интересам, так еще пару раз и на работе в проектах, которые надо делать и завершать вот сейчас, да еще и от не последних людей в компании заказчика. Да и от достаточно авторитетных в отрасли консультантов тоже приходится такое слышать.
Если коротко, то ответить на это можно лишь коаном :)

Учительница говорит Вовочке, - ты зачем обозвал Иванову дурой? Скажи: "Иванова не дура", и извинись.
Вовочка, не могнув глазом: "Хорошо, Мариванна. Иванова не дура?! Ну извините!".


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

Если серьезно, то:
1. Русскоязычного аналога ГОСТов серии 34 нет, все что пытаются сравнивать и предлагать на замену (включая TOGAF, AGILE и много других страшно модных слов) ортогонально требованиям 34.ххх и даже, если противоречит, то в несущественных деталях. Даже то англоязычное, что на моих глазах предлагали на замену и рядом не стояло с 34.ххх. Хотя, на западе тоже есть подобные стандарты, просто никто их никогда не предлагает.
2. Те, кто ругает, но разбирается в ситуации, не любят ГОСТы как раз за то, что там даются предельно конкретные контрольные списки, следуя которым не построить хорошую автоматизированную систему может только безрукий.
3. Описание требований к процессам построения АС прописано в ГОСТ так, что это мешает заходить вперед определенной технологией и поставщиком решения, а к моменту выбора технологии и субподрядчиков становится очевидно, что выбор велик, и никакой уникальности никто не предлагает.
4. И еще рад вопросов:
- кому в организации заказчика нужно успешное построение автоматизированных систем, влекущее за собой все прелести прозрачности и централизованного управления резервами оптимизации всех уровней?
- кому из внешних и внутренних автоматизаторов нужна ответственность за весь пиджак, когда легко можно ограничиться ответственностью за пуговицы?
- кому нужно видение заказчиком полной стоимости владения автоматизированной системой, которое ломает любые общепринятые техники продаж?

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

Раз уж мы пошли по модным словам, то где коаны, там уже и кейсы :) Вот лишь сегодняшние примеры применения западных деловых практик к построению автоматизированных систем:
-  "По словам бывшего сотрудника этого ведомства, Агентство национальной безопасности США тонет в море бесполезной информации, которая только мешает работе" (http://aftershock.su/?q=node/202546). Прямое следствие продажи программного обеспечения, а не автоматизированной системы целиком.
- "Проработав всего шесть часов в тестовом режиме, база [База данных налогоплательщиков Американского налогового ведомства], рассчитанная на одновременное обслуживание до 30 000 пользователей и призванная совершать около 400 000 операций в пиковой нагрузке, потребовала таких доработок, что её создатели схватились за голову."(http://aftershock.su/?q=node/202495) Бюджет проекта 47 млн долларов. На доработки просят еще столько же.
- "Healthcare.gov [Ключевая система, обслуживающая положения закона «О доступной медицинской помощи» (Affordable Care Act) - ключевое обещание избирателям Барака Обамы] и аналогичные ресурсы на уровне штатов запустили 1 октября. ... По причине многочисленных сбоев и неполадок из 20 миллионов человек, уже посетивших эту федеральную "страховую биржу", оформить новый полис смогли менее 10 процентов. В то же время каждый пятый по вине Obamacare потерял прежнюю медицинскую страховку, не получив техническую возможности оформить новую." (там же). За систему просили $93,7 миллиона, затем потолок (как я понял на доработки) вырос до $292 миллиона.
Это происходит прямо сейчас. Пока вы ставите лайки под этой статьей, там в США менеджеры и программисты в поте лица доводят до ума свои системы, которые строились, надо полагать, по своим стандартам.

Кто помнит скандал с ЕГАИС, может сравнить проблемы, бюджеты и последствия.

Вот еще пример.
Когда я работал в одном крупном газовом монополисте Восточной Европы, мне было поручено провести учет всех проектов внутренней автоматизации одного института и собрать в единую программу проектов. В итоге инвентаризации мы с коллегами находили по два-три дубликата проектов, имеющих перекрывающиеся цели автоматизации, функциональный и организационный объем. Это удавалось, так как раз в год можно было забюджетировать и запустить новый проект почти про одно и то же, главное, чтобы названия не совпадали, а project description в уставных документах не были похожи. Не говоря уже о том, как месяцами люди ваяли системы на основе программной платформы, не совместимой с инфраструктурными стандартами компании.

И много других примеров.

Но гораздо более интересно разобрать заинтересованные в гонениях на 34.ххх стороны и их интересы.

Автоматизаторы

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

Однажды, уже квартал, как выпустив одну систему автоматизации проектного управления в промышленную эксплуатацию, мы услышали от финансового департамента:
- Ваша система не работает.
- Почему - удивились мы?
- По тому, что мы не можем получить из нее годовой отчет.

- Но через год вы его получите, раньше данные не собирались.
- Вот тогрда и поговорим.


Почему же автоматизаторы любят ограничивать свою зону ответственности программным обеспечением?
1. Нормальная автоматизированная система хотя бы на 500-1000 пользователей даст отдачу (или докажет свою ненужность) года через 2-3 от старта создания. Не все вообще планируют проработать здесь столько времени. А за написанное ПО можно отчитаться уже за 6 месяцев, получить премию и, скинув сопровождение на младших товарищей, двигаться к новым вершинам. Умными словами: если софт прошел верификацию - это не значит, что он легко пройдет валидацию.
2. ПО гораздо гибче: найдем ошибки - перепишем, чего переживать? Софт, пока он не становится гигантским, дорабатывается относительно легко, а главное быстро. Другое дело, думать, что будет, если система раскорячится на виду у сотен пользователей и придумывать, как этого не допустить. И уже совсем другое дело переучивать эти 800 пользователей раз в месяц из-за ошибок в проектровании. А ведь 800 - это еще маленькая системка, есть большие компании с тысячами, муниципалы с десятками тысяч и федералы с миллионами пользователей.
3. Не надо постоянно бодаться с поставками железа, не надо плохо спать от того, что вдруг, не хватит емкости накопителей, мощности процессоров или надо было брать больше памяти. А цикл поставки нового сервера - месяцы, а если задействован бюджетный цикл - год с хвостиком.
4. Не надо иметь дело с методикой, зашиваемой в информационную технологию. Это всегда касается вопроса, как людям работать не в плоскости нажимаемых кнопок, а по существу - какие задачи решать, каких результатов достигать, как выстроена цепочка прибавленной стоимости, как распределены вдоль нее вкладываемые ресурсы и ответственность. Это все вопросы неприятные, а на самом деле - конфликтные.
5. Ты вообще не последнее звено, а значит есть, куда перебросить часть недоделанной работы. Каждая вторая первая реакция на ошибки софта и проблемы с производительностью - это проблемы эксплуатационщиков с настройкой оборудования и системного ПО сервера.

ГОСТ 34.ххх однозначно решает все вышеперечисленные вопросы не в пользу автоматизаторов. Генподрядчик построения АС берет на себя ответственность за повышение показателей объекта автоматизации - суть автоматизированной деятельности. Составы работ перечислены достаточно ясно, некоторые работы не предписываются, но хотя бы упоминаются так, что неизбежным встает вопрос о разделе ответственности за ряд результатов между заказчиком и генподрядчиком.

Продажники и лица, приравненные к ним

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

И это не случайность.
В сметах на корпоративные системы управления, которые я видел и многие из них сам составлял есть такие факты:
- стоимость лицензий и железа не превышает 15% полной стоимости создания системы.
- стоимость внешнего технологического и бизнес коконсалтинга не превышает 30% стоимости создания системы.
- все остальное - внутренние трудозатраты заказчика.

Если взять полную стоимость владения за 5 лет, то стоимость железа, лицензий и консалтинга меркнет совсем.

Теперь представьте себя продающим инициативу: что проще продать и/или забюджетировать лицензии на $Х или систему, стоимостью владения $10Х-$50Х. Учтите, что второй вариант дополнительно сопряжен с инвестициями длительностью 2-5 лет и по определению не пролезет в 1 бюджетный цикл. Такие вещи делаются лишь от большой нужды.
В такой ситуации гораздо проще продать какую нибудь программную платформу или программно-аппаратный комплекс - это помещается в 1 год, стоит не очень дорого, а затем влечет за собой работы по развитию, обслуживания и сопровождению - каша из топора.
Казалось бы, почему нет? Но важно понимать, что для большого класса систем есть ряд решений, закладываемых в основу. В первую очередь - методика и собственно, информационная технология, а там дьявол кроется в мелочах, причем не в тех, которыми обычно заказчики любят выносить мозг исполнителям.
В итоге начинать с платформы, а затем уже достраивать информационную технологию бывает крайне затратно и системы не взлетают достаточно часто.

ГОСТ 34.ххх предписывает вполне четкую стадийность: требования заказчика, концепция, ТЗ, тепроект. Никак не наоборот. Выбор конкретного поставщика - это стадия ТЗ, выбор марок покупного ПО - это стадии ТЗ или технического проекта. В итоге при заходе вперед поставщиком и конкретной маркой ПО в системе оказываются полностью провалены решения концептуального слоя. Пусть, они и занимают иногда три страницы текста - их необходимо принять.
Как я уже говорил, нормальная концептуальная проработка с определением целей автоматизации и просчетом альтернативных вариантов, полной стоимости владения и ТЭО за редкими исключениями снимает иллюзию эксклюзивности поставщика и марок базового ПО. У заказчика появляется выбор, а он здесь никому не нужен.

Еще ТЭО, выполняемое на стадии Концепция позволяет самому главному заказчику (который, кстати, отвечает разными органами тела за растрату денег компании) честно взглянуть на полную стоимость владения и не умереть от сердечного приступа. Так как на другой чаше весов там лежат прогнозируемые выгоды, которые часто превышают затраты.

Но как только мы называем цифру прогнозируемой экономии ресурсов компании, на дыбы встают пользователи.

Пользователи

Эти несчастные люди часто и так работают с переработками, гонимы и пинаемы менеджерами, часто в ситуации катастрофического недоснабжения ресурсами. Они помнят уже несколько попыток автоматизации, от которых в лучшем случае ничего кроме необходимости вести двойной учет не видели. В худшем случае они получают еще и вожделенную менеджерами прозрачность и учет, которые никогда не облегчают жизнь простых работяг.
Я могу привести пример двойных журналов в школах: бумажных и электронных, или ужасы (для оператора) плохо спроектированных электронных очередей, которые я наблюдал в ГИБДД и налоговой инспекции. Но гораздо лучше об этом уже написали коллеги из поколения моих родителей, наблюдавшие все ту же картину еще в СССР: http://levkonoe.livejournal.com/879323.html.

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

"Беда" 34.ххх в их излишней конкретности. Они не говорят "мыши, станьте ежиками". Они говорят, какие конкретно решения должны быть приняты чтобы построить АС. Они говорят, в каком порядке должны быть приняты эти решения. А это во многих случаях мешает хоть и по разному, но практически всем.
Да, там, в ГОСТах, есть не все. Но внятная идеология и словарные определения вкупе с инженерным образованием дают возможность достроить картинку и работать хорошо. Никто не мешает дополнять другими стандартами и практиками, благо пересечений минимальное количество. В конце концов, не знаете - спросите меня :)

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

Tags: ,

(Leave a comment)

Boatman's Home Powered by LiveJournal.com