Опора на стандарты. Опора на стандарты. Опора на стандарты. Уж сколько раз твердили миру… Мы живем в эпоху перемен. Перемен столько, что единственная постоянная вещь сегодня — это твердая уверенность в том, что завтра перемены будут продолжаться. Информационные технологии меняются еще быстрее, чем окружающий мир, — им ведь нужно не просто поменяться, а попробовать несколько вариантов и наконец выбрать тот, который наилучшим образом соответствует переменам в реальном мире бизнеса и отношений. Каким образом я могу быть уверен, что все деньги, которые я вложил в ИТ не пропадут и я смогу хоть как-то использовать мои наработки в будущем?
Единственный метод, который может с определенной степенью вероятности гарантировать такую «совместимость с будущим», это опора на стандарты. Если ваша система использует сегодняшние стандарты информационных технологий, то вероятность ее интеграции и применения в будущем очень серьезно возрастает. Если вы используете систему с закрытым форматом данных, с частными протоколами обмена и другими нестандартными интерфейсами, то, скорее всего, вы окажетесь в сложной ситуации в достаточно обозримое время.
Рассмотрев базовые принципы построения информационных систем, можно перейти к основам внедрения информационных систем. Как ни странно, но мир информационных технологий достаточно «стандартизирован» — очень сложно найти ситуации, где не годится одна из небольшого количества стандартных методик. В свое время я объехал немало заказчиков, планируя проекты по внедрению СУБД. И каждый заказчик объяснял мне, что именно его организация и ее структура являются уникальными: «Мол, Клавдия Петровна не подчиняется Сергею Михайловичу, хотя это было бы логично. А вот этот филиал работает непосредственно с поставщиком, а не через центральный офис». Я внимательно выслушивал эти истории, а потом спрашивал, какая все-таки организация отношений у них в компании — матричная или иерархическая Дело в том, что на таком уровне абстракции, как построение иерархии СУБД, меня совершенно не волновали особенности отношений в компании — только связи между различными подразделениями и направление передачи данных. А вся сложность таких отношений была в первую очередь связана с проблемами в управлении компанией, а не с технической реализацией этих отношений: данным совершенно безразличны родственные связи начальника департамента. Более того, за все время работы я не встречал компаний, которые не укладывались бы в иерархическую схему управления с небольшими модификациями. Невольно вспоминаешь «Трудно быть богом» Стругацких:
«Румата задрал подбородок.
— Зарубите на носу, дон Рэба, — сказал он высокомерно. — Для нас, коренного дворянства метрополии, все эти Соаны и Ируканы, да и Арканар, были и всегда останутся вассалами имперской короны».
Описанный выше подход все-таки основывается на знании технологий. Пусть поверхностном, но определенном техническом понимании систем. А что делать, если у руководителя нет «технической жилки»? Если он или она гуманитарий? Бизнес в России в основном развивали инженеры и физики но ведь не только они. Существует и другой способ оценки различных технологических решений. В его основе лежит очень простая идея: основной продукт, с которым работают информационные системы, — это... (сюрприз! сюрприз!) информация. Пусть технической стороной, носителем, который обеспечивает обработку этой информации, занимаются специалисты. Подход к компьютерным системам как к способу работы с информацией дает необходимый уровень абстрагирования от деталей, оставляя за руководителем понимание всей системы в целом.
Вообще-то компьютерные технологии могут работать с любой информацией. Это может быть поиск сообщений внеземных цивилизаций в записях сигналов радиотелескопов или запись последнего хита группы «Корни», но для бизнес-целей обычно используются другие типы информации: записи о продажах, контактах с покупателями, финансовые расчеты, хранящиеся на складах товары, документы, контракты, электронная почта и многое другое. Какими же свойствами должны обладать информационные системы для бизнеса?
