лабораторная. Внедрение ИС. Нарваткина Н. С. Внедрение информационных систем 2019
 Скачать 0.94 Mb.
|
|
Резюме В заключение отметим, что регламентируя взаимоотношения между проектами и эксплуатацией, следует заранее определить понятия, зафиксировать, что является опытной эксплуатацией, что опытно-промышленной, а что — промышленной эксплуатацией автоматизированных информационных систем. Если эти понятия не определить, не описать процедуру передачи и сопровождения систем, то через какое-то время множество критических для бизнеса приложений будет «плавать» в состоянии опытной эксплуатации. Но чем это плохо? Только тем, что нет одного ответственного за сбои? Не только: дело в том, что в этих случаях ресурсы проектировщиков не высвобождаются для других проектов. А насколько они велики? Ведь если говорить о проектах закупки и внедрения систем, то они требуют уже других ресурсов… Подчеркнем еще раз, что разработка программного обеспечения и создание автоматизированной информационной системы (совокупности функциональной части, технического, информационного, программного, организационного обеспечения, коммуникаций и персонала) — это разные не по масштабам, а по содержанию проекты. Программы в основном разрабатываются in-house, включая сложные программные системы. И гораздо реже покупаются в готовом виде. Но «информационные системы» в принципе делаются на заказ. Хотя часто это «внутренний заказ», и разработка системы ведется in-house (собственными силами). Поэтому ввод прикладной системы в действие, например, в банке не означает ее опытную, опытно-промышленную и даже промышленную эксплуатацию. Это — использование системы заказчиком, сопровождение программного обеспечения разработчиком и обеспечение работоспособности (эксплуатации) системы службой поддержки. Развитие информационной системы в ходе постоянной эксплуатации — неизбежность ее жизненного цикла. Не признавать этого — лукавство…. Основным выводом, который следует сделать из «противопоставления» проекта и эксплуатации, будет следующее: опытная и опытно-промышленная эксплуатация не является по своей сути эксплуатацией промышленной. На этих этапах полная ответственность лежит на проектировщиках и разработчиках, эксплуатационная служба не несет ответственности за эксплуатацию разработанной автоматизированной системы, и здесь единственно возможным решением может стать организация внутри проекта собственной службы тестирования и администрирования системы. Для этой цели можно выделить необходимые ресурсы из смежных подразделений либо привлечь в проект специалистов необходимой квалификации (на временной основе) извне. При таком подходе за счет увеличения сроков опытной и опытно-промышленной эксплуатации количество внедрений в эксплуатацию промышленную может быть резко сокращено. Ответственность за опытную эксплуатацию в полной мере будет нести проектная команда, не затрагивая компетенции и не перекладывая непомерно высоких рисков на службу эксплуатации. Обсудите это с вашим проектным менеджером и службой эксплуатации. Кто из них окажется готов взять на себя ответственность и риски опытно-промышленной эксплуатации «рабочих версий» системы, тот вместе с ответственностью должен будет получить и необходимые для этого права! Впрочем, авторам приходилось встречать и «перманентные» проекты, которые не имели ни четко очерченных сроков, ни зафиксированных целей и задач. Точнее, цели и задачи были, но они постоянно менялись, дополнялись, расширялись, уточнялись, и, соответственно, сроки постоянно сдвигались, плыли, переносились. Это, видимо, было выгодно всем участникам проекта, ибо снимало с них какие бы то ни было обязательства по достижению конкретных целей и завершению «проекта» в обозримые сроки. ОЦЕНКА ЭФФЕКТИВНОСТИ ВНЕДРЕНИЯ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ Оценка эффективности информационных технологий, экономический эффект отдельных ИТ-проектов неизменно интересуют топ-менеджеров и владельцев бизнеса, но довольно редко удается получить достоверную и конкретную информацию такого рода. При этом следует выделить два временных среза для такой оценки: бизнес-кейс (business case) — анализ с точки зрения экономического эффекта до запуска проекта и оценка фактически достигнутых результатов. В основе оценки эффективности лежит системный подход, без которого вряд ли может обойтись любая деятельность ИТ-менеджера. Поэтому для начала рассмотрим возможные цели внедрения. Они могут быть весьма разнообразны. Не претендуя на полноту, попробуем перечислить некоторые из них. Возможные цели внедрения 1. Снижение операционных издержек. В этом случае с помощью ИТ сдерживается рост расходов на персонал, повышаются скорость и точность исполнения операций. В качестве простейшего примера можно привести внедрение системы автоматизации бухучета с нуля. 2. Выпуск на рынок нового продукта. Например, если вы задумали эмитировать пластиковые карты, вам для учета карт и операций по ним понадобится соответствующая информационная система. 3. Создание условий для выпуска новых продуктов. Это нечто совершенно отличное от предыдущего. Для реализации такой цели недостаточно внедрить какие-то приложения. Для быстрого выпуска продуктов сама архитектура ИТ-систем должна быть гибкой, способной к адаптации. Решением может быть построение SOA. 4. Повышение качества и скорости обслуживания клиентов. Всем известно, что недовольный клиент о своём негативном опыте расскажет, как минимум десятку других потенциальных клиентов. Достичь большей удовлетворенности можно, например, за счет повышения пропускной способности вашей информационной системы, что в свою очередь складывается из разных составляющих, начиная от каналов доступа в Интернет и заканчивая переделкой архитектуры прикладных систем. 5. Поддержка увеличивающейся доли рынка. Эта цель выглядит довольно просто, но нередко упускают из виду, насколько существенно ИТ-системы могут влиять на возможность расширения бизнеса. Например, если пропускная способность вашей ИТ- системы составляет пять тысяч операций в день, то сколько бы вы ни увеличивали число филиалов, сколько бы ни давали рекламы, больше операций вы сделать всё равно не сможете — только очереди недовольных клиентов вырастут, а репутации будет нанесен урон. Бизнес лишь понесет убытки, а ваша доля рынка не увеличится. 6. Улучшение качества управленческих решений. Это может касаться как стратегического управления, так и создания, например, моделей оценки кредитоспособности, используемых в ежедневных операциях. 7. Выполнение требований регулирующих органов. Одна из самых распространенных наших задач. Неисполнение этих требований может привести к отзыву лицензии на совершение банковских операций. 8. Уменьшение совокупной стоимости владения. Например, если оборудование в течение года загружено неравномерно и есть ярко выраженные немногочисленные пики, имеет смысл рассмотреть возможность его аренды на условиях выделения вычислительной мощности по требованию и таким образом снизить совокупные расходы на поддержку. Критерии достижения цели После того как цели будут определены, нужно сформулировать, по каким критериям можно оценивать их достижение. Несмотря на кажущуюся очевидность этого этапа, здесь зачастую возникают весьма суровые препятствия. Одно из них — явное или скрытое нежелание оценивать результат. В такой ситуации дальше просто не о чем говорить. Если же потребность в оценке все-таки есть, то для того чтобы она была адекватной, необходимо выполнить еще несколько условий. 1. Прежде всего нужна связанная с бизнес-стратегией ИТ-стратегия, иначе неясна будет общая ценность достигнутых результатов. 2. Не менее важен формализованный проектный подход. Следование ему позволяет видеть проект целиком от бизнес-кейса до оценки результатов в отчете о завершении работ. Уверенный системный менеджмент в ИТ и вытекающая из него системность оценок позволят рассмотреть картину в целом. Ведь внедряя одно приложение, мы можем получить целый букет результатов, не всегда прямых. Способы определения эффективности внедрения 1. В ряде случаев можно посчитать эффект применения ИТ напрямую — например, внедряя систему скоринга при выдаче кредитов, вы снижаете риски их невозврата на вполне определенную величину. Но оценка прямого результата не всегда возможна или может быть недостаточно полной, и в таких случаях нужно рассматривать косвенные результаты. Например, увеличение пропускной способности информационной системы приведет не только к росту продаж, но и к большей удовлетворенности клиентов и партнеров за счет уменьшения времени ожидания. 2. Оценка рисков - еще один способ оценки эффективности ИT-проектов. Допустим, ваш банк выдает пять тысяч кредитов в день, сто долларов с каждого — ваш доход. (Все цифры совершенно условные.) При этом в силу разных обстоятельств в месяц набегает один день простоя, который обходится в 500 тысяч долларов. Но если внедрить внешний сервис поддержки приложений, то появляется возможность снижения времени простоев вдвое. Тогда за него можно заплатить 250 тысяч и даже не торговаться, так как будут еще и косвенные результаты в виде возросшей удовлетворенности партнеров в устойчивости работы. Но, конечно, это всего лишь подход к оценке, в реальности всегда нужно учитывать множество других факторов для определения истинной цены. 3. Оценить эффективность можно и через стоимость компании, хотя и это не очевидный путь. На мой взгляд то, что многие российские банки сейчас принялись внедрять западные системы, — не всегда оправданно. Ни одна западная система в наших условиях так, как было задумано ее разработчиками, работать не будет. Некоторые банки их уже используют, но это стоит огромной крови. Либо западная система должна работать в паре с российской. При оценке таких проектов, возможно, целесообразней смотреть на рост капитализации, а не на операционный эффект от внедрения. Такой же эффект может дать сертификация ISO 9001. Примеры оценки эффективности 1 ПРИМЕР. Уменьшение потерь с помощью системы предотвращения мошеннических операций, задействованной при выдаче кредитов Предположим, ваш банк имеет какой-то уровень потерь от мошенничества при выдаче кредитов. Уменьшить эти потери на вполне прогнозируемую величину можно с помощью системы предотвращения мошеннических операций, задействованной при выдаче кредитов. Для оценки эффективности от её внедрения придётся учесть стоимость лицензий, оборудования, консалтинга, интеграции, всех видов поддержки и расходов на персонал. Соотнести все это нужно с сокращением потерь от невозврата кредитов за счет использования экспертной системы. В данном примере можно вполне точно просчитать бизнес-кейс и оценить фактические результаты, сравнив полученные бизнес-показатели с периодом до внедрения системы при условии, что параллельно не внедрялся другой функционал, приводящий к аналогичным эффектам. 2 ПРИМЕР. Оценить эффективность внедрения интеграционной платформы или хотя бы её центрального компонента — шины данных (ESB), Рассмотрим другой пример. Оценить комплексный проект, такой как внедрение интеграционной платформы или хотя бы её центрального компонента — шины данных (ESB), может быть особенно сложно. Первый шаг, как мы и договорились выше, — сформулировать бизнес-цели проекта. В данном случае целей несколько. возможность постепенной замены отдельной бизнес-системы на новую без остановки бизнеса. поддержка требуемых объемов бизнеса. возможность выпуска комбинированных продуктов. И это далеко не полный список. Второй шаг - от перечисленных бизнес-целей можно переходить к целям ИТ. Хотя это всего лишь взгляд на бизнес-цели через призму информационных технологий. Цели внедрения IT: 1.на первом месте стоит построение надежной и управляемой среды взаимодействия приложений. 2.на втором — сокращение расходов на последующую интеграцию. 3.затем появятся широкие возможности для мониторинга бизнес-процессов. 4.и наконец гибкость архитектуры. Подключать новые приложения можно будет чуть ли не в режиме онлайн. При этом мы сможем для каждой задачи в рамках исполнения основного бизнес-процесса выбирать информационные источники из числа подключенных к шине и переключать их на ходу. 5.И это еще не всё, что дает интеграционная платформа. Третий шаг - выбрать критерии достижения целей для такого проекта. Сама по себе — это задача нетривиальная. 1. Первое, что приходит в голову, — оценивать общую производительность информационных систем, рассматривая как непосредственные показатели, так и возможность ее увеличения. Очевидно, что нужно сравнивать положение до и после внедрения платформы. Зачастую, однако, такая прицельная оценка невозможна ввиду того, что в организации могут идти многие другие проекты, как внедренческие, так и организационные. В этом случае нужно попытаться определить, какую долю проект внедрения интеграционной платформы вносит в общий результат. Например, используя возможности шины данных, мы перешли от синхронного обмена сообщениями с автоматизированной банковской системой к асинхронному. В результате пропускная способность системы увеличилась на тысячу кредитов в сутки. Нетрудно посчитать, что расходы на проведение этой доработки в данном случае окупаются за один рабочий день. 2. Другой способ оценки заключается в аллокации части эффекта от внедрения прикладной системы на интеграционной платформе. В данном случае совсем не очевидно, по каким правилам определять эту долю, ведь интеграция приложений с использованием шины данных менее трудоемка, чем без нее. Следовательно, по трудозатратам долю определять нельзя и нужно принимать какие-то иные алгоритмы. Самым очевидным и одновременно самым трудным для (высококачественного) расчета является сравнение вариантов интеграции point-to-point с вариантом использования ESB. По собственному опыту мы можем сказать, что больше пяти систем интегрировать без шины данных не имеет смысла. Практика эксплуатации созданного нами интеграционного решения показала, что действительно применение ESB позволяет быстро подключать новые приложения. Каждый следующий «раунд» интеграции, подключение каждого нового приложения действительно обходится дешевле предыдущих. Что касается создания «надежной и управляемой среды взаимодействия», то это достигается широкими стандартными возможностями масштабирования, высокой отказоустойчивостью индустриальных решений, широкими возможностями мониторинга, применением стандартных технологий (например, Java). 3 ПРИМЕР. Внедрение процесса управления мощностями (capacity management) Рассмотрим другой пример — внедрение процесса управления мощностями (capacity management). Оценить эффективность такого проекта можно только через риски. Бизнес- задачей в этом случае будет создание плана управления емкостью информационной системы. План должен соответствовать показателям бизнес-плана по количеству транзакций. В качестве критериев оценки можно выбрать разнообразные риски сбоев и замедления обслуживания клиентов, закупки ошибочного оборудования и лишних лицензий и т. д. и т. п, список здесь может быть весьма обширен. Например, не имеет смысла покупать тысячу лицензий на рабочие места бизнес- системы, если система не справится с таким количеством пользователей. Другими словами, имея оценку емкости информационной системы, можно сэкономить огромные деньги и направить их на поиск альтернативного решения для доступа к информации. Ещё пример. Допустим, вы покупаете сервер за 500 тысяч долларов США. Однако через полгода понадобится его модернизация стоимостью 300 тысяч, которой хватит еще на полгода. В то же время можно было приобрести сервер достаточной мощности за 700 тысяч (сэкономив таким образом 100 тысяч), которого хватит на больший период времени. Или, скажем, в случае превышения допустимой нагрузки работа информационной системы может замедлиться, что приведет к очередям клиентов, неудовлетворенному спросу, недовольству клиентов и партнеров. И всё это можно оценить. Вот алгоритм решения подобных задач со стороны ИT и должен предложить процесс управления мощностями. Оценить стоимость внедрения процесса можно с учётом прямых расходов на дополнительные компоненты (мониторинг, тестовые среды и т. д.) и их поддержку, стоимости контрактов. Потребуется также учет трудозатрат персонала на поддержку процесса. Для этого придется построить систему учета рабочего времени, которая позволит сделать ИТ-службу более управляемой в целом. Резюме Можно ли вообще так считать? Практика показывает, что можно, мы сами так делаем, когда есть необходимость. А часто ли так считают? Насколько мне известно, нет. Надо ли всегда считать? Думаю, тоже нет. Например, зачем считать каждый отдельный подпроект в рамках запуска старт апа, рассчитанного на год? Перейти к детальной оценке эффективности имеет смысл после того, как установится нормальная операционная деятельность. Другими словами, нет универсального рецепта, есть только подходы. В каждой конкретной организации будет своя специфика, равно как и в каждом конкретном проекте. ОСОБЕННОСТИ ВНЕДРЕНИЯ КИС НА ПРЕДПРИЯТИЯХ Факторы успеха внедрения корпоративных информационных систем Можно выделить следующие основные факторы, повышающие вероятность успеха внедрения КИС: 1. Осознание руководством предприятия крайней необходимости внедрения корпоративных информационных систем и понимание основ их построения. Ключевым фактором, без которого, фактически, не следует начинать проект, является поддержка внедрения со стороны высшего руководства (а лучше, собственников) компании. У руководства успешного предприятия, в большинстве случаев, четко определены стратегические и тактические цели его развития, в том числе, в области автоматизации. Вообще, сейчас трудно найти руководителя (особенно, на крупных предприятиях), который не хотел бы с помощью современных средств автоматизации усовершенствовать управление предприятием и оптимизировать его расходы. Правильно внедренная КИС наряду с предоставлением возможности оперативного сбора, хранения и анализа производственных и финансовых данных способствует значительному повышению исполнительской дисциплины сотрудников предприятия и обеспечивает построение прозрачной для руководства структуры и последовательности процессов его деятельности. В то же время перед внедрением |