Издание CIO публикует список признаков, на которые ИТ-директору следует обращать особое внимание. Именно эти девять признаков могут служить сигналом общего неблагополучия. А также того, что развитие ИТ-инфраструктуры на предприятии движется в каком-то не совсем правильном направлении.

 Хоть по факту описано всего 6 признков, а не 9 на эти признаки очень полезно обратить внимание не только руководителю подразделения ИТ, но и руководителям предприятия - это действительно верный способ оценить "здоровье" ваших ИТ и, при необходимости, вовремя сделать нужные спасительные иньекции. 

Это еще раз напоминает о необходимости тщательно планирования, ибо без него ИТ-архитектура, по мнению специалистов издания CIO, развивается без руля и ветрил. Это может закончиться коллапсом. Ибо слишком часто решения о наращивании по какому-то инфраструктурному направлению ведутся изолированно, без учета общего плана.

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

 Казалось, что это (ручной перенос данных) должно уже быть в далеком прошлом. Но, увы, нет. И этим гршат даже аутсорсеры и интеграторы предлагая подобные решнеия своим заказчикам. Плох тот руководитель, который подобные решения принимает.

Вторым сигналом, который говорит о проблемах, является наличие большого количества «точечных решений». Разумеется, все хотят работать с «лучшими решениями в классе». Но в результате сотрудники вынуждены работать со слишком большим количеством различных приложений. Это увеличивает расход времени, кроме того за всеми этими решениями необходимо следить и не забывать продлевать лицензии. К слову, наличие «зоопарка» решений приводит, в том числе, и к необходимости переносить данные вручную. Все это повышает расходы и замедляет бизнес-процессы. Также растет вероятность сбоев.

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

Третьим симптомом является наличие более одного приложения, решающего каждую конкретную проблему. Казалось бы, два решения на одну проблему лучше, чем одно, и это повышает устойчивость при сбоях. Но это только «казалось бы», в реальности не так. Часто такое случается при объединении компаний, на каждую задачу оказывается по два разных решения. Такие ситуации «оттягивают» силы ИТ-отдела на поддержку ПО, вместо решения стратегических задач. Также впустую улетают деньги.

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

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

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

 Тут вопрос к термину "слишком много". Для разных предприятий это "слишком много" будут разными цифрами. Тут вопрос лучше ставить так, используются ли системы управления базами данных и управляющием интерфейсы от которых можно было бы отказаться в пользу других с целью унификации? Т.е. если основная учетная система использует MS SQL, а CRM работате на ORACLE, то почему? Нельзя ли было и то и другое разместить на одной системе управления данных?

Еще одной проблемой является использование «обходных путей», решение каких-то вопросов на «живую нитку». Обычно так приходится поступать под давлением сроков или финансов. Часто никто не знает, что все «прикручено проволочкой» или «приклеено скотчем», пока какой-то ключевой специалист не увольняется. В результате система становится недостаточно устойчивой. Такую систему может обслуживать только специалист, который прошел «специальное обучение» и знает именно такие хитрости и обходные пути.

 А вот эту проблему диагностировать очень сложно. Как правило подобные "нарывы" вскрываются только при каких-то форсмажерных ситуациях и усугубляют их. Спасение только одно - документирование. Но об этом на 95% ни кто не задумывается. А надо бы. Вскрывать такие проблемы можно только "учениями", т.е. эмулировать форс-мажерные ситуации и смотреть как их отрабатывает отдел ИТ.

По материалам www.allcio.ru