Одна стратегия в IT

Автор: Лысенко Андрей Николаевич
e-mail: alyssenko@yandex.ru

Overshooting или «перелет» при выборе средства – давно известный термин, по некоторым экспертным оценкам часто наблюдается ситуация, когда заказчик использует в лучшем случае 20% купленной функциональности, особенно это заметно в секторе тяжелых ERP платформ. Что же получается? В погоне за гибкостью каждое новое очко дается все дороже и дороже! С другой стороны – «недолет», когда выбранная система начинает ограничивать бизнес через полгода – год, если уже не на этапе внедрения. Как же угадать золотую середину, притом, чтобы IT не стало средненьким или даже посредственным? Для начала надо разобраться с проблемой взглянув на потребности рынка – не секрет, что самым динамичным и активным является малый бизнес, затем идет средний и самым неповоротливый – крупный. (это легко объясняется численностью компаний, рисками, схемами управления и т.д.) Но с другой стороны именно самому динамичному бизнесу и требуется самый гибкий, а значит и как следствие самый дорогой IT! Вот и получается, что гибкость в первую очередь нужна тем, кто не может ее купить, а часто  просто относится к IT как вспомогательной функции. Для решения этой задачи предлагается рассматривать понятие гибкость IT как совокупность двух качеств: первое - готовность обслуживать бизнес в случае количественного роста потребностей, второе – готовность обслуживать бизнес в случае качественного роста потребностей. В первом случае можно в меньшей степени делать ставку на мобильное IT и в большей степени на эффективное, во втором случае нужно делать ставку именно на мобильность IT и чуть в меньшую на его эффективность. Исходя из размеров IT потребностей, компания должна выбирать собственную стратегию поддержания и развития IT. Например для крупной компании, где хорошо известны бизнес-алгоритмы, потоки, загрузки, тренды – острее стоит вопрос эффективности и качества, что приводит к появлению таких процессов как: унификация IT, внедрение ITSM и ITIL, мониторинг в том числе и проактивный, прагматичный подход к ПО пропагандирующий более высокий коэффициент используемости продуктов. Для малого бизнеса, ввиду его мобильности, ценности имеют другие аспекты: гибкость IT, дешевизна. Компаниям, как потребителям, так и поставщикам явно надо иметь в виду эти факторы.

В первой части статьи была попытка пристально взглянуть на проблему, разобраться – почему же эффективность (высокая отдача) и гибкость (толерантность к изменениям) IT часто становятся просто лозунгами. Сейчас попытаемся разобраться каким же образом можно попытаться добиться эффективности и гибкости.

Начнем с эффективности, тем более, что уже существуют компании доказавшие результативность подходов в решении этого вопроса. Для увеличения эффективности целесообразно: унифицировать программные и аппаратные составляющие (ликвидировать «зоопарк»), повысить их утилизацию (виртуализировать вычисления, исполнять прагматичный подход в выборе средств и услуг). Эти приемы позволят добиться реальной экономии средств и усилий при сравнимой функциональности и производительности.

Как увеличить гибкость, если под гибкостью понимать не способность линейно наращивать производительность при увеличении аппаратной мощности, а настоящую гибкость дающую определенную степень свободы системе от ее составляющих и их функциональных производных или готовность обеспечивать работоспособность при гипотетической трансформе комплекса? Гибкость бывает двух уровней: гибкость архитектуры и гибкость приложения/сервиса. В первом случае целью ставится гибкость на уровне глобальных задач: бизнес – потоков и алгоритмов, систем как атомарных величин, во втором – гибкость конкретного приложения/сервиса. На макро уровне целесообразно применить принцип «смещенной гибкости», т.е. создать постоянный, со значительным overshooting-ом, но качественный (масштабируемый, производительный, полнофункциональный, надежный) аппаратно-программный «хребет» и на него наращивать более изменчивые модули (приложения, сервисы и т.д.). Осуществляя политику гибкости на макро-уровне рекомендуется следовать идеологии SOA, четко определить спецификации взаимодействия систем, сделать все потоки макро уровня прозрачными, создать качественную систему поддержки качества данных корпоративного уровня и т.д.. Второй уровень гибкости в меньшей степени определяется стратегическими векторами и в большей степени зависит от идеологии и собственных функционально-тактических возможностей модулей. Маневрировать на втором уровне можно только делая правильный выбор способа решения задачи (от заказной разработки до EPR).

 Качество – интегральный показатель, общая оценка IT. Тем не менее для  повышения этого показателя на современном рынке существуют целый каскад решений позволяющих добиться надлежащего эффекта: мониторинг, ITIL, ITSM, Change Management и т.д., хороши любые средства позволяющие повысить прозрачность, прогнозируемость и контроль IT.

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

Автору известны примеры, когда компании принципиально отказались развивать существующее IT и приняли решение отстраивать его заново.