Мир продвинулся вперёд! Почему мы не продвинулись вместе с ним?
Программное обеспечение ERP было построено на предпосылке, что компании сконфигурируют или изменят решение до того, как установят его, а не после. Подобно традиционному подходу, как только эти решения были установлены, немногие ожидали, что они усовершенствуются, переформируются, изменятся, и будут устанавливаться повторно, не успев устареть. Эти старые системы были внедрены ИТ-профессионалами, которые часто меняли место работы: документации просто не существовало, а новая рабочая сила не имела никаких навыков в кодировании старого программного обеспечения.
Не удивительно, что компании отсрочивали, избегали обновления версий программного обеспечения, а лишь корректировали его и создавали свои ветки версий. Стоимость этих усилий была огромна относительно выгод, полученных из новой конфигурации или функциональных возможностей. Организационный ущерб был наивысшим. Но если стоимость и ущерб превышали имеющиеся возможности, то риск изменений при обновлениях версий может вообще иметь непредсказуемые последствия, выражаясь в новых и неизвестных технических проблемах, что означает реальную опасность краха всего бизнеса для компании.
Поэтому, трансформационное изменение систем, было популярно в специальных книжных изданиях и презентациях на заседаниях, но вне их вызывало усмешки, а порой и громкий смех среди тех, кто разбирался в технологии и знал, когда это осуществится в ERP решениях. Некоторые специалисты считали, что проблема лежала не в поле управления изменениями. Но проблема заключалась в дизайне проекта, рожденном и развитом для вчерашних статических бизнес целей.
[Перепечатка материалов 12NEWS.ru разрешается только с предварительного согласования с редакцией или автором. Если вы читаете этот материал на другом ресурсе, пожалуйста, сообщите нам об этом editor@12news.ru]
В чём суть?
Когда возникает необходимость новых деловых процессов и стратегий, бизнес продолжает действовать «вопреки нуждам». Как сказали бы психологи, и без инфраструктуры бизнес нуждается в сегодняшней окружающей среде, а не в будущих средствах. Это означает, что бизнес-процессы реализуются прошлым методами и практиками. Бизнесу вслепую приходится начинать новые проекты, при этом, урезая свои возможности маневра, а в итоге предлагать нестандартное обслуживание клиентам, идти против ожиданий инвестора и вопреки стандартным подходам.
Может быть, детектор лжи или анализ крови, но что-то нам должно дать понять, что ERP продавцы не выполняют поставленных обещаний из десятилетия в десятилетие. Помните, как XML, Unix/client-сервер, объектно-ориентируемое программирование, Web-приложения, технологии интеграции сети, и т.д., всё это продвигало ERP-приложения, чтобы сделать их проще и легковнедряемыми. Еще сервис-ориентируемая архитектура (SOA) – ведь фактически каждый поставщик до сих пор надеется на неё. В этом деле нужна здоровая доза скептицизма.
Требования от ERP гибкости в различной степени более или менее поддержаны, но скорость разработок под бизнес задачи – совсем другая история. Не существует доказательств того, что многие ERP вендоры были способны к быстрому, дешевому и точному, изменению поставляемых ими систем. Было замечено, что некоторые главные вендоры работают только в определенных сферах бизнеса отраслевой специфики и имеют только постоянный круг пользователей, и к тому же не имеют ресурсов для миграции к более новым архитектурам.
Это не говорит о том, что SOA или подобные реализации не будут улучшать качественно обработку бизнес-информации. Но это - не панацея, и она столь же хороша, как и архитектура, на которой она базируется. Если, однако, поставщик имеет приложение, которое было разработано для определенных бизнес-целей, SOA будет делать изменения в этих решениях намного более легкими для внедрения для других целей.
Легко говорить о скорости, но в действительности сложно изменить ERP- приложения. Почему? Большинство разработок использует словарь данных. Эти инструменты определяют технические признаки относительно областей данных в пределах ERP-системы. Большинство ERP теперь включает инструмент изменения потока данных и изменения словаря. Однако, что действительно необходимо – это включить возможность настройки бизнес-логики на уровне этих данных. Например, большое ERP-решение не позволит кому-то эффективно изменить структуру данных, без вмешательства в зашитую бизнес логику в интерфейсах систем. В большой системе невозможно перемещать или сужать области данных для использования в другой группе бизнес логики, если эта информация требуется для другой критической обработки и анализа.
Данные и логика должны быть связаны так, чтобы «интеллектуальная» адаптация могла пройти быстро, легко и правильно для всех ERP-решений. Ничего другого для увеличения скорости подгонки готовых систем к существующим бизнес процессам не нужно.
Примечательно то, что некоторые вендоры преднамеренно держат многое из их инструментария изменения структуры данных бизнес приложений, скрытых внутри некой черной коробки. Они делают это, потому что их решения настолько хрупки и неперемещаемы, что они не осмеливаются позволить клиенту заглянуть внутрь, и использовать это в той области, которую разработчики и не предполагали. И они даже называют себя «открытыми», а потом удивляются, почему большинство из клиентов и нас предпочло бы встретить их менеджеров по продажам у дверей, чтобы провести некоторые испытания, которые доказали бы, что они столь же «чисты», как об этом говорят.
Управлять изменениями сегодня, а не завтра
Почему же важно техническое проворство пользователям-ERP сегодня? Давайте для примера посмотрим на профессиональные сервис-фирмы. Программирование, архитектурная работа, TRIZ-разработка, X-ray и MRI - все это выполняется в странах с дешевой рабочей силой подобно России, Китаю или Индии. Компании этих стран редко сотрудничали с другими фирмами.
Теперь, компании пробуют построить глобальные модели поставки обслуживания, где проекты укомплектованы совместно с государствами с дешевой рабочей силой, которая обслуживает одинаково и поставщиков, и профессионалов. К примеру, новые сервисы обслуживания, подобно бизнес процессам, требуют, чтобы организации были партнерами с компаниями поставщиками технологий, инвесторами, специализированными поставщиками обслуживания. Сотрудничество необходимо, чтобы сделать компании более конкурентоспособными и более успешным в глобальной экономике. Реализованы в большинстве ERP эти возможности по партнёрству в сервисах, совместной проектной работе, глобальной объединенной поддержки? Нет.
Например, изменения в бизнесе, воздействующие на фирмы сервисного обслуживания, оставили большинство ERP-поставщиков решения в смущенном состоянии. Сервис-фирмы нуждаются в недорогих решениях, которое позволит им сокращать общее количество затраченного времени, требуемого, чтобы вести и завершать проекты. Сегодняшние проекты и их соответствующие организационные команды - смесь безостановочного сотрудничества. Современные сервис провайдеры работают в режиме 24/7, используют проектные команды, работающие во всем мире. Ведение баз знаний, гибкая изменяемость бизнес-процессов и всевозможных аналитические срезы, помогающие ходу обслуживания в системе - чтобы «не было бы заложено возможностью», а «хорошо бы, чтобы уже было в системе».
Современная скорость изменений в системе отражения бизнес процессов, - это не то, что ERP разработчики предполагали десятилетия назад. Это - время для новой крови автоматизации бизнеса и новой политики реализации возможностей в решениях традиционных поставщиков.
Брайен Соммер - президент Techventive
Адаптация и перевод 12NEWS©
© Галактика, 2006
© Издание 12NEWS (ИП Маринин А.Л.), 2006