Во многих, вероятно, в большинстве крупных компаний, занимающихся снабжением, отдел информационных технологий имеет годы накопившихся задач. Задачи состоят из множества неполадок, несоответствий или хрупкостей, которые могут быть исправлены, но не исправляются. Помимо создания огромных бюрократических издержек, эта бесконечная серия бессмысленных неприятностей подавляет всех. Снабжение, находящееся прямо посередине прикладного ландшафта, особенно пострадало. Как справедливо отмечается, доля снабжения1 часто составляет половину всего накопившегося задела отдела информационных технологий компании.

Роль информационных технологий в вашей цепочке поставок

Что хуже, накопившиеся задачи часто затмеваются неким Великим Переходом, обычно обновлением ERP-системы. Это является прямым следствием того, что от Великого Перехода ожидается решение всех проблем, которые остались нерешенными в последнее десятилетие. Однако это ожидание ошибочно. Действительно, Великий Переход, даже успешно завершенный2, через полдесятилетия приведет к возникновению множества новых проблем, даже если он сумеет устранить некоторые из старых.

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

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

Среди крупных компаний такой подход преобладал в последние два десятилетия. Результаты плачевны. Компании до сих пор платят огромные суммы за CRUD-приложения3, которые должны были быть коммодифицированы - с помощью открытого исходного кода - более десяти лет назад. Задержки внедрения никогда не были такими долгими. Вишенкой на торте является то, что производительность и отзывчивость прикладного программного обеспечения по-прежнему остаются такими же низкими, как и два десятилетия назад, в то время как базовое оборудование стало в 1000 раз более мощным.

Эта ситуация требует глубокого исправления: отдел информационных технологий должен перестать действовать как Великий Архитектор от имени всех других отделов. Вместо этого отдел информационных технологий должен стать тренером для других отделов, с исключительным фокусом на инфраструктуре4, оставляя все остальное отделам с менталитетом возможности.

Позиция Великого Архитектора неприемлема: даже коллективно отдел информационных технологий не может знать все, что нужно знать о финансах, маркетинге, продажах, заработной плате, производстве, бухгалтерии, транспорте, планировании, соответствии, юридических вопросах и т. д. Человек, умеющий всё, испортит большинство инициатив, которые он предпринимает. Каждая недоделанная доставка приводит к появлению новых проблем, которые позже нужно исправлять. Генерация накопившегося задела неизбежна и бесконечна. Поскольку программное обеспечение становится все более распространенным с каждым годом, накопившийся задел становится все более неуправляемым каждый год.

Решение проблемы простое5: отказаться от “Великого Архитектора” и переориентировать IT-отдел как фактор, способствующий и наставник для всех программных инициатив, выполняемых другими отделами. Передача отделам, таким как цепочка поставок, ответственности за свои собственные программные инициативы заставляет их пересмотреть свои амбиции: больше нет козлов отпущения за то, что накопилось слишком много задач. Отдел несет ответственность как за свои успехи, так и за свои неудачи.

Однако решение практически никогда не реализуется.

Переориентация IT-отдела как фактора, способствующего, означает сокращение его бюджета на половину или более, что является прямым следствием значительного сокращения операционной деятельности компании. Это неприемлемо для руководителя IT-отдела, чья должность часто соперничает с должностью генерального директора во время Великого Перехода.

Это также означает, что руководители отделов должны стать ответственными за свои собственные программные инициативы - или их отсутствие. Удобно перекладывать вину на IT, когда проект идет не по плану - что часто случается в программном обеспечении. Это также позволяет отделам избежать проблемы с наймом IT-специалистов, с которой они сталкиваются уже десятилетия.

Тем не менее, по мере того как корпоративное программное обеспечение переходит к SaaS (программное обеспечение как услуга), перспектива “Великого Архитектора” постепенно утрачивает свою актуальность, поскольку поставщики берут на себя обеспечение хостингом, резервными копиями, обновлениями и т. д. Таким образом, хотя и случайно, руководители отделов постепенно вынуждены становиться ответственными за свои программные решения, а IT-отдел постепенно вынужден отказаться от своих прежних обязанностей.

Корпоративное программное обеспечение пришло на вечеринку SaaS с десятилетним опозданием. Я предсказываю, что большинству крупных компаний потребуется еще десять лет, чтобы выйти из мышления “Великого Архитектора”.


  1. Задолженность в цепочке поставок принимает множество форм: теневое IT бушует, Excel повсюду, операции / клиенты / поставщики остаются в неведении, запасы / заказы / отгрузки не синхронизированы между системами, вместо автоматизации царит ручной ввод и т. д. ↩︎

  2. В этих Великих Переходах есть только один победитель: поставщик программного обеспечения, возглавляющий процесс. За 15 лет я ни разу не видел, чтобы многолетнее обновление принесло что-то большее, чем тонкую инкрементальную улучшение. Однако я видел, как поставщики программного обеспечения совершали впечатляющие возвраты от этих операций снова и снова. ↩︎

  3. Создание, чтение, обновление, удаление. CRUD-приложения - это основа корпоративного программного обеспечения. Почти все приложения для рабочих процессов и транзакционные приложения являются CRUD-приложениями. ↩︎

  4. Сети, федерация идентичности, операционные системы, резервное копирование и т. д. ↩︎

  5. До 2000-х годов сложно было объединить корпоративное программное обеспечение через интернет. Таким образом, привлечение разнородного программного обеспечения и последующее их соединение не было особо вариантом до 2000-х годов; конечно, не дешевым. Ранние корпоративные системы начались как монолит из необходимости, а не из выбора. Таким образом, “исправление”, представленное выше, стало реалистичным вариантом только в начале 2010-х годов. ↩︎