ITBlogs

Опубликовано в Intelligent Enterprise, №13-14 (207), 18 сентября 2009 года (http://www.iemag.ru/analitics/detail.php?ID=19592)

Отдельная благодарность Андрею Колесову за комментарии при подготовке статьи.

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

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

Противопоставление единой системы и «кусочной автоматизации» — одна из популярнейших тем в сфере ИТ, и однозначный ответ, как и в других «религиозных» спорах, никогда не будет получен. Для российских представительств международных компаний этот вопрос чаще звучит несколько видоизмененно — внедрять глобальное или локальное решение. Здравый смысл опять же, по вышеперечисленным причинам, голосует за глобализацию. Но тем не менее локальные решения появляются, и срок их жизни в некоторых случаях сопоставим со сроком жизни глобальных ре­шений.

Причины и предпосылки создания локальных решений

Для начала постараемся проанализировать причины появления локальных решений.

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

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

Другая популярная причина для возникновения уникальных решений — это уникальность самого процесса. Классический пример — законодательство, предъявляющее иногда взаимоисключающие требования в различных странах. Например, несмотря на все усилия по гармонизации законодательства между государствами Европейского экономического союза, автоматизированные системы государственной регистрации автомобилей по‑прежнему различаются в каждой отдельной стране.

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

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

В российском отделении компании «Форд» реализовано и поддерживается более десятка локальных решений. Например, решение для бухгалтерии на базе «1С: Бухгалтерия», о реинжиниринге которого я подробно писал в статье «Почему у нас получилось» в № 10/2009 Intelligent Enterprise. В 1999 году, во время запуска завода, остро встал вопрос о бухгал­терской системе, отвечающей требованиям российского налогового учета. В то же самое время в Европе происходила миграция на новую бухгалтерскую систему (PeopleSoft), и свободных ресурсов не было. Кроме того, «Форд» уже имел негативный опыт внедрения глобального решения в Беларуси, когда полученная отчетность не была принята белорусской налоговой инспекцией, что привело к значительным штрафам и необходимости перевести все транзакции в «1С: Бухгалтерию». Поскольку будущее российского рынка было весьма туманно после кризиса 1998 года, то вкладывать значительные средства в доработку PeopleSoft для соответствия российским требованиям не имело смысла, а позитивный опыт использования решения на базе «1С: Бухгалтерии» на заводе в Беларуси утвердил руководство в решении создать аналогичное и для российского завода.

Риски локальных решений

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

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

Во-вторых, постарайтесь заглянуть в будущее, близкое и не очень. Может быть, уже через год рост объемов или ожидаемые изменения законодательства приведут к необходимости масштабируемого решения и оправдают дополнительные ресурсы, необходимые для запуска глобального решения сегодня. Создание по‑настоящему масштабируемого решения — дорогое, небыстрое и наукоемкое занятие.

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

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

Еще одна проблема, которая стоит перед крупными компаниями, — это возможное снижение управляемости и прозрачности. В России было и есть много примеров компаний, владеющих розничными сетями, когда даже более продвинутые, но уникальные системы в регионах заменялись единым реше­нием.

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

Создав локальное решение для бухгалтерии, мы столкнулись с несколькими из этих рисков. Во-первых — масштабируемость. Первая версия системы разрабатывалась только для автоматизации бухгалтерского учета при запуске завода. В дальнейшем область работы системы серьезно расширялась десятки раз. Был добавлен автомобильный учет офиса продаж, взаиморасчеты с поставщиками и другие модули. Рост продаж и производства автомобилей привели к превышению пределов масштабируемости решения (но не самой платформы «1С»). Для решения этой проблемы в 2008 году был успешно проведен реинжиниринг системы с одновременным переходом на новую версию платформы.

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

Недостатки глобальных решений

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

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

Еще один вечный бич глобализации — недостаток гибкости. Обычно система поддерживает несколько вариантов реализации того или иного процесса, и пока ваши запросы находятся в реализованной области, вы не встретите проблем. Но стоит вам иногда даже в сущей мелочи отклониться от области существования решения, и ваши пожелания могут оказаться объективно невыполнимыми либо потребовать доработок в нескольких смежных областях. Тестирование может стоить совершенно непропорциональных усилий.

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

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

Легкие решения

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

***

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

Опубликовано в Intelligent Enterprise, №10 (204), 10 июня 2009 года (http://www.iemag.ru/projects/detail.php?ID=19092)

В январе 2009 года в российском подразделении компании «Форд» успешно завершился проект по реинжинирингу бухгалтерской системы на платформе «1С». Проект был завершен в соответствии с планом и без превышения бюджета, несмотря на то что из первоначально запрошенных 18 месяцев нам было выделено только 12. Хотя согласно статистике, опубликованной Standish Group в апреле 2009 года, только 32% проектов завершаются успешно, в срок и без превышения бюджета.

Автоматизация в компании «Форд» представляет собой десятки, если не сотни систем. Некоторые из них глобальны и используются во всех представительствах или на заводах «Форд» по всему миру, другие решают уникальные задачи, например связанные с необходимостью соответствовать уникальным юридическим требованиям в конкретной стране. Один из примеров — системы регистрации автомобилей. Во многих странах процессы, связанные с регистрацией, автоматизированы, но единой международной системы на данный момент не существует. С другой стороны, система планирования заказа запчастей используется практически на всех автосборочных заводах «Форд» по всему миру. Причины существования такого обширного портфеля различных решений состоят не в отсутствии единой стратегии или методологии, а в возрасте самой компании и в том, что на заре компьютерной эры компания «Форд» была в первых рядах фирм, которые начинали использовать информационные технологии для нужд своего бизнеса.

Локальная система в качестве тактического решения

Первая версия «1С: Бухгалтерии» была запущена в российском представительстве «Форд» еще в 1999 году. Первоначально планировалось использовать эту систему исключительно для бухгалтерского учета, связанного с запуском завода «Форд» в городе Всеволожске (июль 2002 года). На тот момент европейские офисы компании «Форд» находились в процессе перехода с мэйнфреймовой бухгалтерской системы DB GL на PeopleSoft. Ни бюджета, ни ресурсов для запуска PeopleSoft в России запланировано не было. Кроме того, у компании уже был негативный опыт использования глобальной системы DB GL для ведения бухгалтерского учета на белорусском заводе «Форд», выпускавшем модели Escort и Transit (1997—2000 годы). Надежды менеджеров «Форд» на согласие белорусской налоговой инспекции принять бухгалтерскую отчетность в том виде, в котором она подготавливается в Европе, не оправдались. «Форд» был вынужден заплатить значительный штраф и заново ввести все транзакции в срочно установленную версию «1С: Бухгалтерии». Опираясь на полученный опыт, руководство проекта приняло решение внедрить локальный продукт в качестве тактического решения для организации бухгалтерского учета.

В дальнейшем функционал системы многократно расширялся и активно развивался. Был добавлен автомобильный учет для вновь организованной национальной компании продаж, взявшей на себя импорт и таможенную очистку автомобилей, а также доставку автомобилей дилерам по всей стране. В последующие годы автомобильный учет был расширен за счет включения других марок, таких как «Вольво», «Лэнд Ровер» и «Ягуар». Бухгалтерский учет в российском офисе был по‑прежнему организован в единой системе, но каждая марка использовала свой набор систем, из которых необходимо было получать информацию по автомобилям и запчастям. Область использования системы расширилась во много раз, что привело к предсказуемым проблемам: запутанная иерархия объектов, отсутствие адекватной документации, особенно для функционала, разработанного на заре существования приложения, узкие места, возникавшие по мере роста рынка и популярности автомобилей марки «Форд» в России.

На конец 2007 года система обслуживала более 170 пользователей, объем базы вырос до 45 Гб. Система обменивалась информацией, используя более 120 интерфейсов с двумя десятками отдельных систем, включая экспорт отчетности в PeopleSoft («Форд», «Ягуар» и «Лэнд Ровер») и SAP FI («Вольво»), взаимодействие со складским модулем SAP R/3, используемым для склада запчастей, и другие.

Бухгалтерия как узкое место

В рамках проекта по расширению производства для выпуска 125 тысяч автомобилей в год, включая 25 тысяч автомобилей новой для российского завода модели «Мондео», система «1С: Бухгалтерия» была идентифицирована как одно из узких мест, препятствующих увеличению производственных мощностей и сопутствующих объемов продаж. Специфика проблемы состояла в том, что перепроведение транзакций, осуществляемое в рамках бухгалтерского закрытия месяца для выстраивания транзакций в последовательную цепочку, не укладывалось бы более в сроки, диктуемые корпоративными правилами финансового учета. Для группы поддержки «1С: Бухгалтерии» проблема была не новой. Однако все остальные действия, за исключением реинжиниринга, уже были применены: автомобильный учет был выделен в отдельную базу; работа с базой данных переписана с внутреннего языка «1С» на TransactSQL; эффективность процедур, наиболее влиявших на длительность перепроведения, повышена до максимальных значений, возможных в текущей конфигурации. Все эти меры принесли свои плоды и продлили срок действия первоначальной конфигурации.

Но мы, наконец, достигли пределов масштабируемости устаревшей архитектуры системы — она стала жертвой успеха марки «Форд» на российском рынке. В 1999 году «Форд» продал 1363 машины за весь год, в 2008 году было реализовано более 227 тыс. автомобилей различных моделей. Экстенсивный подход к увеличению производительности за счет увеличения мощности серверов не имел смысла, так как корень большинства проблем оказался в блокировках. Кроме того, достаточно мощные конфигурация серверов, сформированные в соответствии с корпоративными стандартами «Форд», были усилены в первую очередь за счет добавления оперативной памяти.

Новая архитектура системы

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

Не меньшее значение придавалось созданию и обновлению документации о системе с целью подготовки миграции на глобальные решения, повышению качества оперативной поддержки и упрощения клонирования системы для марок, выделяемых в отдельные юридические лица. Возможность создания копии системы с последующим переводом активов по тем или иным признакам была одним из важных принципов при выстраивании новой структуры объектов. Чтобы улучшить сервис, предоставляемый бухгалтерии, и автоматизировать подготовку корпоративной отчетности, нужно было включить в новую систему параллельный учет в соответствии с принципами МФСО. И если в случае учета реализации автомобилей было бы возможно генерировать отчетность по МФСО на основе главной книги по РСБУ, то в случае с производственным функционалом транзакции, сформированные в соответствии с РСБУ, не содержали бы достаточной информации для создания отчетности в соответствии с МФСО.

Воля к победе

Начиная с ноября 2008 года было организовано несколько встреч, посвященных анализу проекта. Мы старались ответить на вопросы: «что можно было сделать лучше?», «что получилось?» и «что дальше?».

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

Основа методологии — активное участие заказчика

Не менее важной предпосылкой успеха проекта являлось планомерное и последовательное применение методологии компании «Форд» в области развития информационных систем. Один из основных столпов этой методологии — обязательное участие и лидирование заказчика системы при составлении спецификаций. Такой подход требует значительных затрат времени от заказчика системы, но одновременно обеспечивает высокое качество продукта на выходе.

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

Хотя отнюдь не все внешние предложения были приняты. Например, решение об использовании конфигурации «1С 7.7 Форд» в качестве базовой для проекта осталось неизменным, несмотря на рекомендации экспертов из KPMG взять за основу одну из базовых конфигураций «1С: Бухгалтерии 8.1» — кому, как не нам, знать, насколько серьезным и множественным доработкам была подвергнута оригинальная конфигурация. По нашей оценке, в существующей конфигурации было адаптировано более 80% функционала стандартной конфигурации. Пусть в некоторых случаях (например, при установлении корреляций с МФСО) нам пришлось «заново изобретать велосипед», уже присут­ствующий в стандартном пакете «1С: Бухгалтерии 8.1», тем не менее мы уверены, что альтернативой было еще более значительное количество повторных разработок в области специфического для нашей компании функционала.

Последние три месяца, после начала тестирования новой конфигурации, к которому были привлечены практически все сотрудники бухгалтерии (более 40 человек), каждое утро начиналось со встречи с участием каждого из руководителей отдельных групп бухгалтерии и руководителя проекта со стороны ИТ. Обязательность тестирования и формального подтверждения каждого, сколь угодно незначительного, нового функционала сотрудниками отдела, использующего систему, — еще один столп методологии развития ПО в нашей компании. На этой встрече контролировался процент приемки функционала. Обсуждались любые вопросы, возникающие в процессе тестирования системы пользователями. В случае возникновения задержек оценивалось влияние задержки на запуск проекта. Затем оставалось найти решение, позволяющее не выбиться из графика.

Управление ресурсами и приоритизация

Сам запуск можно охарактеризовать 119 часами сверхурочных работ на трех штатных специалистов по «1С: Бухгалтерии» отдела ИТ за первые два месяца 2009 года и тем, что уже мартовское закрытие прошло без необходимости в сверхурочной работе ИТ-специалистов. Такие сравнительно скромные затраты были обусловлены четким еженедельным контролем статуса и периодическими проверками ключевых контрольных точек проекта. Когда летом были просчитаны сроки завершения работы над основным функционалом, выяснилось, что часть критичных подсистем не укладывается в необходимые сроки. Были срочно добавлены дополнительные программистские ресурсы, и сроки возвратились в необходимые рамки. Здесь стоит выразить благодарность компании «СофтБаланс», которая смогла предоставить нам необходимые дополнительные ресурсы для выполнения проекта. В дальнейшем, по мере приближения времени запуска и завершения разработки новой системы, экспертами со стороны бухгалтерии и ИТ была введена жесткая приоритизация объектов. Команда сконцентрировалась на тех объектах, работа которых была необходима с первого дня, а многие отчеты были отложены. Кроме того, была отложена разработка налогового плана счетов. Этот функционал сформулирован консультантами в рамках проекта, но внедрение отложено до второй половины 2009 года. По результатам проекта нехватка времени выделена как одна из областей, которые могут быть улучшены. Это позволило бы внедрить налоговый учет в рамках проекта в полном объеме, более тщательно изучить предложения консультантов по оптимизации и «пролить меньше крови» при запуске. С другой стороны, нельзя сказать, что мы многим пожертвовали, уложившись за год.

Другая «вечная» проблема такого рода проектов, которая не обошла и нас, — недостаток «освобожденных» участников проекта со стороны заказчика — бухгалтерии. Только один сотрудник занимался проектом почти 100% своего времени. Безусловно, каждый из сотрудников отдела внес свою лепту в успешное завершение проекта, но выделение еще двух-трех «освобожденных» аналитиков безусловно положительно сказалось бы на качестве и сроках тестирования, не говоря уже о сэкономленных нервах бухгалтеров, для которых работа над спецификациями и тестирование добавились к основным должностным обязанностям.

Хотелось бы отметить еще один из уроков проекта — это более глубокое и регулярное ознакомление сотрудников бухгалтерии с новыми возможностями как новой конфигурации, так и самой системы «1С: Бухгалтерия 8.1». Было бы полезно заранее, до запуска, более подробно ознакомить бухгалтеров с особенностями нового плана счетов, правилами соответствия РСБУ и МФСО.

В срок и в рамках бюджета

В январе 2009 года проект по реинжинирингу бухгалтерской системы завершился. Были достигнуты поставленные цели: быстродействие системы увеличено в соответствии с ближайшими потребностями, причем с запасом — с выделением автомобильного учета в отдельную базу можно параллельно работать над различными областями учета. Гибкость новой архитектуры системы вкупе с возможностями новой версии «1С: Бухгалтерии 8.1» позволяет нам меньшей кровью и более оперативно изменять систему в соответствии с меняющимися требованиями бизнеса и законодательства. Количество сверхурочных часов во время месячного закрытия сокращено. Ключевые процессы, бывшие узкими местами в старой конфигурации, значительно ускорились. Например:

• перепроведение транзакций в рамках месячного закрытия сократилось с 40 часов до 16;
• проведение продажи одного автомобиля ускорилось с 7 секунд на один авто до 2 секунд (для оценки — даже сейчас, во время кризиса, «Форд» продает около 10 тысяч автомобилей в месяц);
• перевыставление счетов на все автомобили «в трубе» (в пути к российским дилерам) раньше занимало два дня, теперь — три часа.

Все это было достигнуто в срок и в рамках утвержденного бюджета.

1. Цели инвестиций (из сфо)
1. Обязательные
2. Снижение издержек
3. Модернизация
4. Развитие
2. Проектный бюджет: принципы
1. Владелец системы и запросы на развитие
2. Уместность и оправданность капиталовложений
3. Требования и затронутые стороны
4. Цели и результаты
5. Стоимость и ограниченность людских ресурсов
6. Локализация
3. Финансовые разделы обоснования проекта:
1. риски при отказе от проекта (включая упущенную выгоду),
2. просчёт различных сценариев
4. Различные типы проектных расходов:
1. 1кап вложения (железо+уникальный софт)
2. 1услуги (программирование…)
3. 2расходы на запуск решения (сертификация…)
4. 3операционные расходы первого года после внедрения проекта,
5. 2расходы на команду запуска,
6. 2командировочные итд
5. Различные типы расходов на сотрудников
1. Штатные
2. Агентские
3. Услуги
6. Обсуждение бюджета (обсуждение за столом из другой презентации)
1. Бизнес задачи (заранее обсудить с потребителями!)
2. Проектные издержки
3. Постоянные издержки (влияние проекта на структуру издержек)
4. Бюджет предприятия (место проекта в общем бюджете, приоритеты)
5. Снижение расходов
7. Исполнение бюджета (человек с лупой или лупа, вечеринка в баре, перенос или перестановка элемента мозаики, человек внутри круга, человек с разными атрибутами или многорукий Шива)
1. Контроль ИТ над ИТ бюджетом
2. Нецелевое использование
3. Перераспределение фондов
4. Контроль использования ресурсов внутри отдела
5. Контроль использования бюджета как интегральная часть выполнения проекта (sdm weekly status)
8. Проектные риски (взрыв, разрывающий что-то, лист бюджета или "кривая расходов", регулировщик, хелпдеск, возможно замученный)
1. Изменение области
2. Исполнение бюджета
3. Управление изменениями
4. Поддержка
9. Партнеры (заказчик, человек с мешком денег, человек с кучей телефонов)
1. Заказчик/потребитель
2. Финансы
3. Закупки

Контактное лицо - Елена Скалон, e.skalon at thi-s.ru

The Center of Excellence (CoE) is an integral part of the Information Technology organization providing support to the business for all Global Applications

Within the CoE, the incumbent is responsible for driving and managing both on-going support for the business and Change Request resolution as well as for supporting key project initiatives for the following 5 Global Finance Processes worldwide: FI/CO/FMD/BCS/BW.

He/she

• Plans, directs, and manages the analysis, design and implementation of global applications for these areas to ensure the corresponding business functions can meet their established objectives in a timely manner. Including proactively investigating and bringing forward new SAP functionality to the business.

• Initiates, develops and forges a strong business partnership with business customers. He/she aligns on their priorities and delivers upon the agreed and approved business initiatives.

• Works in concert with headquarters management and field management (markets and factories) in the aforementioned areas to ensure delivered global applications and accompanying business processes support the company’s strategic direction/mission/objectives and local operating requirements.

• Acts as integration lead on all cross functional requests liaising with other R2R Team Leads, other Process Experts within CoE and IT to ensure that all required changes are coordinated across all functional areas and completed on time.

• Maintains the integrity of the FI/CO/FMD/BCS/BW GRM (Global Reference Model) and ensures full compliance with One Change Management process.

• Provides strong leadership to the FI/CO/FMD/BCS/BW team and manages his/her group of Process Experts and Process Analysts. Ensures team meets and even exceeds the performance KPIs established for his/her team.

Education

University degree in Finance, Accounting, or Professional Accreditation

Work Experience

5 + years of financial management experience. Good understanding of JTI’s financial business processes and functions. Awareness of the key support and configuration/development request processes. Knowledge and experience with project management. Working knowledge of SAP.

Language and computer skills

Fluency in English, Working Knowledge of SAP and HPSD

Areas of responsibility

1. This team lead is responsible for driving Support and Change Request resolution. Managing both on-going support for the business as well as supporting key project initiatives from the business and from IT.

1. Serve as integration lead on all cross functional requests liaising with other R2R Team Leads, other Process Experts within CoE and within IT to ensure that all required changes are coordinated across all functional areas and completed on time. Collaborate with other R2R Team Leads, CoE Regional IT Leads (RILs), Global Support Desk and IT/CoE Budgeting Team to ensure that all projects and initiatives are in line with overall company direction, priorities and budgets.

1. Proactively investigate and bring forward new SAP functionality to the business that delivers added value and better meets the business requirements. Deliver consultancy services to the business. (ALIGNMENT). Fully support the training of Power users and End users in order to address any knowledge gaps in the business. (KNOWLEDGE)

1. Participate in the development of the Annual and Strategic financial planning for CoE to ensure consistency of objectives and appropriate budgeting.

1. Maintain integrity of the FI/CO/FMD/BCS/BW GRM (Global Reference Model) while at the same time ensuring that local legal/statutory requirements are met.

1. Ensure full compliance with One Change Management process. Keep all BPMLs, BPFs and configuration documentation up to-date. (STEWARDSHIP & GOVERNANCE)

1. Ensure operating and capital expenditures for CoE – FI/CO/FMD/BCS/BW team are well managed and remain within agreed budgets.  (Budgeting)

1. Provide strong leadership to the FI/CO/FMD/BCS/BW team. Ensure good communication amongst team members and with other CoE teams. Lead his/her group of Process Experts and Process Analysts. (TEAM).
   Ensure adequate staffing levels are maintained and leveraged to address priority business requirements and ensure required cross functional training is completed in order to strengthen knowledge base within the team.
   Provide for the development of personnel both technically and professionally to maintain an effective, efficient, innovative, and proactive organization.  (Personnel) Also initiate and fully support the SAP and Cross functional training of CoE team members. (KNOWLEDGE)

Почему появляются локальные системы?

Существуют объективные и субъективные предпосылки для этого:

Объективные:

глобального решения просто не существует

так как больше нигде нет такого процесса или так как в каждом случае используется локальное решение (процесс уникален в каждом офисе)

запуск глобального решения слишком дорог – нет бюджета

запуск слишком дорог – недостаточные объемы

Субъективные: руководство подразделения не устраивает глобальное процессное или системное решение

Какие проблемы это может создать?

Система окажется недостаточно масштабируемой.

"Изобретение велосипеда" – создание функционала, который уже есть в глобальной системе

Качество решения будет низким в связи с недостатками использованной проектной методологии

Ограниченный функционал, так как было принято решение не реализовывать все возможные ситуации

Невозможность сравнить результаты процессов в разных офисах

Стоимость поддержки системы потенциально может стать сравнимой со стоимостью поддержки глобальной системы

Излишней специфичность бизнес-процессов к конкретном офисе, что может привести к снижению управляемости и прозрачности

Избыточная гибкость локального решения

Проблемы использования глобальных решений:

Негибкость (скорость изменения системы неадекватна скорости изменеия бизнес среды)

Негибкость (частота изменений ограничена)

Дороговизна изменений

Конфликт интересов различных пользователей/офисов

Дороговизна поддержки

Центральная команда слишком "далека от народа"

Corporate IT strategies in Russia and the CIS” Summit 

СЕССИЯ 1: Обзор трансформаций динамично развивающегося рынка и их влияния на задачи CIO:

Глава ИТ ЦентроБанка Михаил Сенаторов рассказывал о централизации ЦОДов. Доклад я к сожалению не услышал - московские пробки, зато в кулуарах мне

рассказали о некоторых фактах, которые остались за кадром. Например о том, что 74 ЦОДа были сведены к схеме 2*2. Т.е. две удалённых друг от друга площадки,

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

Что тут можно сказать... Моё уважение не знает границ. Попытка оценить риски захлёстывает.

СЕССИЯ 2: Как построить взаимовыгодные партнерские отношения между провайдерами и CIO?

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

При этом Ринат Гимранов высказал мнение, что уровень аутсорсинга в стране вырос. Мне кажется, что просто появились некоторые компании, которые научились предоставлять сервис действительно хорошего качества. При этом средний уровень скорее ухудшился, а качественные сервис могут себе позволить только крупные компании типа СургутНефтеГаза или Форд. При этом доступное качество услуг скорее ухудшилось из-за продолжающегося превышения спроса над предложением.

В который раз помянули начало демографической лакуны "детей Перестройки", вернее их отсутствия.

Ещё одна проблема в области аутсорсинга (ей поднял Михаил Михайлов из Мечел) - стоимость. В то время, когда в Европе нормой считается коэффициент 2 (кстати, не только в области ИТ), российские аутсорсеры воют, если коэффициент ниже 4-х. И к сожалению спрос позволяет им не думать о сокращении издержек и повышении качества. :(

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

Другая проблемная область - нежелание вендоров решать проблемы клиента в случае, если проект состоит из нескольких различных решений разных вендоров. Обычно каждый их вендоров до последнего показывает пальцем на другого, утверждая, что с их продуктом уж точно всё в порядке.

СЕССИЯ 3: МОЗГОВОЙ ШТУРМ: Создание согласованной с бизнесом ИТ стратегии

Учитывая наличие Михаила в качестве ведущего и Толи Тенцера в качестве участника - шоу обещало быть интересным. Но неожиданно круче всех зажёг Миэль. Вначале были выступления Михаила Иванова,МеталлоИнвест и Сергея Пегасова, Вимм-Билль-Данн которые рассказали о своём пути разработки достаточно детальной стратегии ИТ. Владимир Львов, к сожалению не смогу участвовать и слово перешло к Генеральному Директору Миэль, Евгению Плаксенкову, упиравшему на то, что ИТ стратегия может и вообще практически должна быть большей частью независима и нечего донимать руководство требованием сформулированной бизнес стратегии. Потом ИТ Директор Миэль, Сергей Захарцев, высказался в струе мол, всё равно ничего не поймут. В общем-то бывает и такое. И бывает успешным - насколько я понял, менеджмент Центробанка практически не осознал укрупнение ЦОД-ов. То, что бизнес часто хочет именно так походить к вопросу согласования - это не новость... Но спорно, спорно.

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

Занятная получилась сессия.

СЕССИЯ 4: НОВАЯ ТЕМА: Роль ИT директора при реструктуризации компании. Задачи ИТ отдела и ИТ директора в условиях пост- М&A, консолидация и подготовка к IPO.

Александр Герман рассказал о своём опыте - его работодателя покупали не раз. Герман Эпштейн поделился своим реальным опытом участия в укрупнении компаний в пивной индустрии. Особо углубляться не буду, сберегу силы, чтобы как-нибудь изложить на бумаге суть своего доклада по этой теме.

СЕССИЯ 5: НОВИНКА Ключевая Презентация Стратега - Paul Coby

Доклад Пола был для меня особенно интересен, так как несмотря на серьёзность задач, которые решаются в крупных российских компаниях, многие вопросы уже давно решены в международных корпорациях и текущие задачи BA и Форд значительно ближе друг другу.

Перечисляя продукты, используемые в компании, Пол упомянул и SAP, и Oracle. В ответ на мой вопрос оказалось, что BA действительно использует и тот, и другой ERP пакет - SAP для инженерной функции, а Oracle - для кадровой службы (интересно, Oracle или всё же PeopleSoft?). В качестве причины такого высокоуровневого зоопарка Пол сослался на ошибку предшественника. Нехарактерное признание.

Рассказывая о запуске нового терминала T5 в Хитроу, Пол упомянул, что работу терминала обеспечивает около 140 систем. Причём Пол не видит особой проблемы в таком разнообразии. !

BA - ещё одна компания, которая выбрала Google в качестве средства для поиска информации в интранете. По мнению Пола это лучше, чем пытаться заставить все функции заносить информацию в Базу Знаний в соответствии с утверждёнными шаблонами.

В ответ на вопрос из зала об использовании аутсорсинга в BA, Пол сказал, что предпочитает термин "партнёрство" термину "аутсорсинг". Не аутсорсинг, а взаимодействие с поставщиком.

Многие функции в компании перенесены на веб - расчётные листки, планирование сверхурочных итд. Кроме того, руководство компании поддерживает диалог с работниками на форумах запущенных внутри компании, так как причина многих трудовых конфликтов часто кроется в непонимании сторонами друг друга, в недостатке общения. Правда, судя по количеству забастовок различных категорий служащих BA, похоже это не особенно помогает.

Часть программного обеспечения в компании до сих пор разрабатывается коллективами штатных программистов. Причём не только для разработки систем, которые представляют из себя конкурентное преимущество. Но, имхо, это ничего не доказывает - возможно это просто дань привычке.

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

СЕССИЯ 7: Механизмы доставки контента, развитие беспроводных и мобильных технологий и управление корпоративной информационной системой

Нина Парфёнова, Мегафон, рассказала о смешанной модели запуска ITSM в Мегафон (8 отделений). Рассказ был интересен откровенным разговором о вопросах возникающих при автоматизации в холдинговых структурах, пусть даже однородных, при наличии нескольких "центров тяжести". Степень централизации в таких структурах - это вопрос без однозначного ответа. Презентация, правда, была типично консультантская, чересчур многословная - сказывается прошлый опыт Нины в Big4.

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

СЕССИЯ 8: Вопросы безопасности и непрерывности бизнеса

Здесь предсказуемо интересны были доклады банковского сектора - Дмитрий Назипов из ВТБ и Сергей Розов из UBS. В своих презентациях они особо упирали на проведение адекватного, а не "для галочки" тестирования планов по восстановлению бизнеса.

СЕССИЯ 9: ОБСУЖДЕНИЕ: Модели управления ИТ отделами

У Макса действительно получилось сделать талк-шоу. И даже не только он говорил. :) Интересный формат, но участие требует нестандартной подготовки. Разговор как минимум выявил тот факт, что подходы в сфере управления отделом по-прежнему многовариантны и здесь есть что обсуждать.

В общем и целом мне очень понравилось.

Страница конференции. 

M&A, зачем?

1)       Любой бизнес можно купить и продать за две недели (Северсталь)

2)       Зёрна от плевел, рост эффективности за счёт специализации (Pretty women)

3)       Экспансия за счёт покупки компаний (Перекрёсток, Росгосстрах, Ford)

Что делать?

Бизнес: Родственники или партнёры?

Унификация – до какого предела?

Полная интеграция или SOA? Включение или замещение?

Уровни интеграции

Структура управления

Бизнес-процессы

Политика в области ИТ

Инфраструктура

Системы, жизненный цикл

Mazda

Японская модель владения

Аутсорсинг

Volvo

Собственные системы

Скандинавская культура доверия

Особенности SOA-подхода

LR

Смены владельца ведёт к смене систем

Фрагментация в сфере ИТ

Вопросы:

Общие системы: что и когда?

Общие системы: линия отреза специфики?

Выбор лучшего решения.