Страница:
Причины разработки стратегии в области информационных технологий
Стандартным подходом корпораций к разработке стратегии ИТ является продолжение финансирования существующих проектов и одобрение финансирования дополнительных проектов, представленных менеджером ИТ, пока заранее установленный потолок затрат не будет достигнут. Этот подход полностью избегает каких-либо увязок инвестиций в ИТ с общей стратегией бизнеса компании, вероятным результатом чего являются потерянные возможности ля совершенствования бизнеса. Однако существует несколько позиций, влияющих на принятие решений по ИТ, где финансовый директор мог бы заявить о необходимости полной оценки стратегии ИТ, создав тем самым более тесное соответствие между проектами ИТ и общим направлением бизнеса. Это возможно:
• Когда сливаются компании. Если компания приобретает другую компанию, то существует вероятность возникновения вопросов о том, чьи системы будут использоваться в тех или иных областях, или следует ли держать системы обособленными. Это подходящее время для проведения тщательного анализа причин, по которым следует использовать системы любой из компаний, что позволяет сохранить наиболее приемлемые из них.
• Когда необходимы крупные сокращения затрат. Если компания обнаруживает, что теряет так много денег, что должна провести детальный анализ всех расходов в масштабе компании, то это хороший повод для анализа стратегии ИТ, хотя этот анализ будет сильно перевешивать в сторону сокращения затрат, а не к использованию этой стратегии для совершенствования бизнеса.
• Когда существует переизбыток заявок на проекты ИТ. Это одна из наиболее типичных причин разработки стратегии ИТ. Менеджер ИТ совершенно завален количеством заявок, поступающих в его отдел, и просит начальство о помощи в разборе этих заявок. В таком случае используется такая стратегия ИТ, которая выступает как сортировочный механизм для отбора самых необходимых проектов.
• Когда имеющиеся системы ИТ не справляются. Если старые, доморощенные системы начинают пробуксовывать по самым разнообразным причинам – уход ключевых программистов, чрезмерный объем операций и т. п. – финансовый директор может ратовать за разработку новой стратегии ИТ, используемой в качестве основы для создания замещающих систем. Единственной проблемой является то, что системы могут меняться так быстро, что процесс разработки стратегии будет поспешным.
• Когда изменяется организационная структура компании. Иногда высшее руководство может решить реорганизовать компанию с учетом географии ведения бизнеса, появления новых менеджеров, управляющих различными направлениями, и т. п. Существующие системы ИТ могут быть перегружены информационными потребностями новой структуры, это благоприятное время для пересмотра стратегии ИТ.
• Когда существующие системы мешают функциональной эффективности. Наиболее часто эта проблема возникает в компаниях, основной целью которых является постоянное сокращение издержек для того, чтобы оставаться производителем с низкими затратами. В результате они сокращают затраты до уровня, когда процедуры, связанные с существующими системами ИТ, становятся помехой дальнейшему совершенствованию себестоимости, что приводит к анализу стратегии с целью выявления возможных изменений в системах для сокращения затрат.
• Когда приходит новое руководство. Если новый генеральный директор вступил в должность и привёл свою управленческую команду, то они могут провести полную реорганизацию всей компании, которая, вероятно, затронет и существующие системы ИТ. Это превосходная возможность для анализа стратегии ИТ, поскольку новые направления могут быть определены без какого-либо вмешательства старой команды менеджеров.
Независимо от того, какое из вышеизложенных обстоятельств используется в качестве повода для создания стратегии ИТ, финансовый директор должен непременно иметь текущий график периодических пересмотров стратегии ИТ, чтобы время от времени можно было вносить в план необходимые коррективы, поскольку общая стратегия бизнеса меняется.
• Когда сливаются компании. Если компания приобретает другую компанию, то существует вероятность возникновения вопросов о том, чьи системы будут использоваться в тех или иных областях, или следует ли держать системы обособленными. Это подходящее время для проведения тщательного анализа причин, по которым следует использовать системы любой из компаний, что позволяет сохранить наиболее приемлемые из них.
• Когда необходимы крупные сокращения затрат. Если компания обнаруживает, что теряет так много денег, что должна провести детальный анализ всех расходов в масштабе компании, то это хороший повод для анализа стратегии ИТ, хотя этот анализ будет сильно перевешивать в сторону сокращения затрат, а не к использованию этой стратегии для совершенствования бизнеса.
• Когда существует переизбыток заявок на проекты ИТ. Это одна из наиболее типичных причин разработки стратегии ИТ. Менеджер ИТ совершенно завален количеством заявок, поступающих в его отдел, и просит начальство о помощи в разборе этих заявок. В таком случае используется такая стратегия ИТ, которая выступает как сортировочный механизм для отбора самых необходимых проектов.
• Когда имеющиеся системы ИТ не справляются. Если старые, доморощенные системы начинают пробуксовывать по самым разнообразным причинам – уход ключевых программистов, чрезмерный объем операций и т. п. – финансовый директор может ратовать за разработку новой стратегии ИТ, используемой в качестве основы для создания замещающих систем. Единственной проблемой является то, что системы могут меняться так быстро, что процесс разработки стратегии будет поспешным.
• Когда изменяется организационная структура компании. Иногда высшее руководство может решить реорганизовать компанию с учетом географии ведения бизнеса, появления новых менеджеров, управляющих различными направлениями, и т. п. Существующие системы ИТ могут быть перегружены информационными потребностями новой структуры, это благоприятное время для пересмотра стратегии ИТ.
• Когда существующие системы мешают функциональной эффективности. Наиболее часто эта проблема возникает в компаниях, основной целью которых является постоянное сокращение издержек для того, чтобы оставаться производителем с низкими затратами. В результате они сокращают затраты до уровня, когда процедуры, связанные с существующими системами ИТ, становятся помехой дальнейшему совершенствованию себестоимости, что приводит к анализу стратегии с целью выявления возможных изменений в системах для сокращения затрат.
• Когда приходит новое руководство. Если новый генеральный директор вступил в должность и привёл свою управленческую команду, то они могут провести полную реорганизацию всей компании, которая, вероятно, затронет и существующие системы ИТ. Это превосходная возможность для анализа стратегии ИТ, поскольку новые направления могут быть определены без какого-либо вмешательства старой команды менеджеров.
Независимо от того, какое из вышеизложенных обстоятельств используется в качестве повода для создания стратегии ИТ, финансовый директор должен непременно иметь текущий график периодических пересмотров стратегии ИТ, чтобы время от времени можно было вносить в план необходимые коррективы, поскольку общая стратегия бизнеса меняется.
Разработка стратегии информационных технологий
Первым шагом в разработке стратегии ИТ является образование рабочего комитета ИТ, наделенного полномочиями по ее разработке. Очень важно, чтобы эта группа состояла из представителей всех основных функциональных подразделений компании и чтобы ее решения имели более высокие шансы быть принятыми всей компанией. Финансовому директору необходимо посещать эти совещания, равно как и менеджеру подразделения ИТ. Следует избегать присутствия на них дополнительных представителей ИТ, если только это не требуется для получения специальной информации, так как велика вероятность, что принятые решения будут направлены на технические направления, а не на весь бизнес в целом. Комитет отвечает за создание стратегий ИТ и установление приоритетов для проектов ИТ, основанных на этих стратегиях, а также должен представить эту работу правлению для окончательного утверждения. Он также рассматривает новые проекты ИТ, предлагаемые различными подразделениями компании. Для того чтобы комитет не увяз в их изучении, он должен ограничить свою деятельность разбором только крупнейших и наиболее дорогих проектов и предоставить возможность менеджеру ИТ заниматься всеми более мелкими вопросами.
После создания рабочему комитету необходимо прежде всего уделить значительное время изучению общих корпоративных стратегий, которые он будет использовать при формулировании стратегии ИТ. Первая стадия изучения может занять всего один день, если официальный стратегический документ уже был подготовлен. Однако более вероятно, что компания работает без него, и в этом случае рабочий комитет должен заслушать членов правления, чтобы собрать информацию, на основе которой он сможет затем разработать план работы.
Процесс изучения главных направлений бизнеса, вероятно, потребует значительного времени на уяснение общей схемы работы компании. Например, члены комитета должны знать, производится ли продукция по заказам или без них, используется один или несколько складов, случаи перепроизводства продукции в прошлом, процедуры многовалютных транзакций, наличие особых требований государственной отчетности, о передаче функций внешним исполнителям («аутсорсинг»), об обмене проектами изделий с поставщиками и т. д. Этот уровень детального понимания операций является критически важным для последующего определения типов проектов ИТ, которые могут быть реализованы с целью наиболее эффективного содействия общей деятельности компании.
Имея под рукой концепцию бизнеса, комитет может затем выработать стратегию ИТ, поддерживающую общие задачи бизнеса за счет акцента на слабых областях, которые в то же время считаются важными для деятельности, а также путем развития направлений, где компания хочет сохранять высокий конкурентный статус. Для этого стратегия должна включать детальный перечень сильных и слабых сторон корпорации, а также стратегических разработок ИТ, влияющих на них. Кроме того, корпорация должна предвидеть возможное соперничество в области ИТ с фирмами-конкурентами, основываясь на достоверности получаемой информации. Другим подходом к разработке возможных стратегий является проведение сравнительного анализа проектов ИТ других компаний, а, возможно, и организаций, находящихся вне отрасли компании. Относительно идей о том, какие типы стратегий могут быть реализованы, смотрите раздел «Конкретные применения» в конце главы. Этот этап является развивающимся процессом, который постоянно обновляется в свете изменений в общей стратегии и поэтому имеет тенденцию к дополнительной корректировке приоритетов, установленных для различных проектов.
Имея в наличии стратегию ИТ, рабочий комитет должен затем определить, какие конкретные проекты ИТ необходимо реализовать для выполнения поставленной цели. Это требует детального знания точных функций ИТ, которые уже выполняются, а также проектов, необходимых для сокращения разрыва между нынешними и желаемыми возможностями. В анализе должны учитываться технические способности отдела ИТ компании, чтобы рассчитать, как много внешней помощи может потребоваться для определенных проектов. В результате изучения собственных ресурсов должно произойти распределение персонала по определенным категориям: специалисты в данной отрасли, специалисты по процессам, эксперты по практическому развитию и персонал по обслуживанию систем. Таким путем комитет может обнаружить те области, где отсутствие квалифицированного персонала чрезмерно затруднит реализацию нового проекта. Комитет должен также рассчитать долю рабочего времени персонала ИТ, затрачиваемого на обслуживание существующих систем ИТ, поскольку оно обычно поглощает основное время работы сотрудников, оставляя мало возможностей для каких-либо работ над нововведениями. Эта проблема иногда может быть преодолена путем разумной замены индивидуально разработанных программ стандартными программами, поддерживаемыми внешней организацией, что сокращает усилия по обслуживанию со стороны отдела ИТ.
Далее, комитету следует провести детальное изучение разрабатываемых в настоящее время проектов, затрат ресурсов и времени, необходимых для их завершения. Во многих случаях может оказаться целесообразным завершить проекты, которые в стадии разработки хотя и далеки от требований стратегии ИТ, но требуют минимальных стараний для окончания.
Этот детальный уровень анализа потребует значительных усилий, особенно если компания имеет много направлений деятельности, мест базирования или отделений. Для того чтобы завершить хотя бы часть этой работы как можно скорее, комитет может ограничить ее объем, концентрируясь только на определенных областях. Критерием ограничения может стать важность для производства полученной в итоге информации, возможность ее использования более чем в одной функциональной области или то, будет ли ее результатом обмен информацией с другими деловыми партнерами. Конечно, доминирующим критерием является констатация в стратегии бизнеса того, что данная конкретная область рассматривается как благоприятная возможность для бизнеса в целом. Если содержание плана ИТ ограничено подобным образом, комитету следует расставить приоритеты в отношении остальных частей бизнеса и включить их в стратегию ИТ, насколько позволяет время.
Даже имея в наличии стратегию ИТ, четко определяющую, какие типы проектов подлежат одобрению, комитету все равно будет непросто расставить точные приоритеты для различных проектов ИТ вследствие широкого разнообразия возможных проектов. Любые или все из приведенных ниже методов, могут быть использованы для проведения такой приоритезации:
• Метод строительного блока. Предоставляйте высокий приоритет тем проектам, которые необходимы как строительные блоки для дальнейших проектов, которые не могут быть завершены, пока не реализованы первые проекты. Например, общекорпоративная сеть должна быть завершена прежде, чем во всей компании может быть установлена система планирования производственных ресурсов.
• Портфельный метод. Когда денежные ресурсы сокращаются, компания имеет тенденцию отменять все рискованные проекты ИТ и концентрирует свои усилия только на тех, которые обеспечивают очевидную и вероятную отдачу. Однако такой подход таит в себе риск никогда не достигнуть прорывного технического преимущества. Лучше определить проекты с высокой потенциальной отдачей и выделить на них небольшую часть бюджета ИТ, даже если существует высокий риск неудачи.
• Метод конкурирующих стандартов. Если проект требует использования одного из комплектов конкурирующих отраслевых стандартов, может быть, целесообразно отложить его реализацию до тех пор, пока не прояснится, какой из стандартов будет играть доминирующую роль. В противном случае, компания может обнаружить, что инвестирует средства в технологию, экспертная база поддержки которой сокращается.
• Принудительное ранжирование. Последовательно сравнивают ценность каждого проекта с каждым другим предложенным проектом для того, чтобы создать ранжирование. Например, проект А сравнивается со всеми другими предложенными проектами. Если комитет считает, что он должен иметь самый высокий приоритет, то ему присуждают этот ранг. Затем комитет индивидуально сравнивает все остальные проекты, чтобы определить следующий самый важный проект. После того, как на основе данного метода расставлены все приоритеты, комитет возвращается к списку еще раз и сравнивает каждый проект в нем со следующим сразу за ним, и повторяет этот процесс до тех пор, пока не будет удовлетворен ранжированием.
• Метод отдачи. Каждое проектное предложение должно сопровождаться расчетом экономической эффективности. Хотя комитет может проигнорировать эту информацию в интересах долгосрочной стратегии, способность проекта ИТ создавать прибыль, особенно при ранжировании среди краткосрочных проектов, не следует игнорировать.
Из только что описанных методов приоритезации, следует уделить особое внимание методу принудительного ранжирования, но в рамках более широкой схемы конкретных стратегий бизнеса. Например, если крупный скачок продаж за счет использования более эффективного персонала с мобильной связью рассматривается как основная стратегия бизнеса, то все ключевые проекты, относящиеся к этой стратегии, могут получить более высокий ранг, чем те, которые относятся к следующей наиболее важной стратегии. После этого может быть использовано ранжирование методом строительного блока, чтобы определить первоначальную приоритетность проектов внутри каждой группы проектов, а принудительное ранжирование может быть затем проведено в отношении остальных проектов.
На всем протяжении процесса определения стратегии ИТ, проведения анализа разрыва с конкурентами и установления приоритетности конкретных проектов, рабочий комитет должен помнить о необходимости детального информирования о своей деятельности правления, отдела ИТ и компании в целом. Это необходимо, чтобы обеспечить наивысший уровень поддержки и сотрудничества всех сторон, когда настанет время реализовывать пакет проектов, которые рабочий комитет рекомендует правлению.
После создания рабочему комитету необходимо прежде всего уделить значительное время изучению общих корпоративных стратегий, которые он будет использовать при формулировании стратегии ИТ. Первая стадия изучения может занять всего один день, если официальный стратегический документ уже был подготовлен. Однако более вероятно, что компания работает без него, и в этом случае рабочий комитет должен заслушать членов правления, чтобы собрать информацию, на основе которой он сможет затем разработать план работы.
Процесс изучения главных направлений бизнеса, вероятно, потребует значительного времени на уяснение общей схемы работы компании. Например, члены комитета должны знать, производится ли продукция по заказам или без них, используется один или несколько складов, случаи перепроизводства продукции в прошлом, процедуры многовалютных транзакций, наличие особых требований государственной отчетности, о передаче функций внешним исполнителям («аутсорсинг»), об обмене проектами изделий с поставщиками и т. д. Этот уровень детального понимания операций является критически важным для последующего определения типов проектов ИТ, которые могут быть реализованы с целью наиболее эффективного содействия общей деятельности компании.
Имея под рукой концепцию бизнеса, комитет может затем выработать стратегию ИТ, поддерживающую общие задачи бизнеса за счет акцента на слабых областях, которые в то же время считаются важными для деятельности, а также путем развития направлений, где компания хочет сохранять высокий конкурентный статус. Для этого стратегия должна включать детальный перечень сильных и слабых сторон корпорации, а также стратегических разработок ИТ, влияющих на них. Кроме того, корпорация должна предвидеть возможное соперничество в области ИТ с фирмами-конкурентами, основываясь на достоверности получаемой информации. Другим подходом к разработке возможных стратегий является проведение сравнительного анализа проектов ИТ других компаний, а, возможно, и организаций, находящихся вне отрасли компании. Относительно идей о том, какие типы стратегий могут быть реализованы, смотрите раздел «Конкретные применения» в конце главы. Этот этап является развивающимся процессом, который постоянно обновляется в свете изменений в общей стратегии и поэтому имеет тенденцию к дополнительной корректировке приоритетов, установленных для различных проектов.
Имея в наличии стратегию ИТ, рабочий комитет должен затем определить, какие конкретные проекты ИТ необходимо реализовать для выполнения поставленной цели. Это требует детального знания точных функций ИТ, которые уже выполняются, а также проектов, необходимых для сокращения разрыва между нынешними и желаемыми возможностями. В анализе должны учитываться технические способности отдела ИТ компании, чтобы рассчитать, как много внешней помощи может потребоваться для определенных проектов. В результате изучения собственных ресурсов должно произойти распределение персонала по определенным категориям: специалисты в данной отрасли, специалисты по процессам, эксперты по практическому развитию и персонал по обслуживанию систем. Таким путем комитет может обнаружить те области, где отсутствие квалифицированного персонала чрезмерно затруднит реализацию нового проекта. Комитет должен также рассчитать долю рабочего времени персонала ИТ, затрачиваемого на обслуживание существующих систем ИТ, поскольку оно обычно поглощает основное время работы сотрудников, оставляя мало возможностей для каких-либо работ над нововведениями. Эта проблема иногда может быть преодолена путем разумной замены индивидуально разработанных программ стандартными программами, поддерживаемыми внешней организацией, что сокращает усилия по обслуживанию со стороны отдела ИТ.
Далее, комитету следует провести детальное изучение разрабатываемых в настоящее время проектов, затрат ресурсов и времени, необходимых для их завершения. Во многих случаях может оказаться целесообразным завершить проекты, которые в стадии разработки хотя и далеки от требований стратегии ИТ, но требуют минимальных стараний для окончания.
Этот детальный уровень анализа потребует значительных усилий, особенно если компания имеет много направлений деятельности, мест базирования или отделений. Для того чтобы завершить хотя бы часть этой работы как можно скорее, комитет может ограничить ее объем, концентрируясь только на определенных областях. Критерием ограничения может стать важность для производства полученной в итоге информации, возможность ее использования более чем в одной функциональной области или то, будет ли ее результатом обмен информацией с другими деловыми партнерами. Конечно, доминирующим критерием является констатация в стратегии бизнеса того, что данная конкретная область рассматривается как благоприятная возможность для бизнеса в целом. Если содержание плана ИТ ограничено подобным образом, комитету следует расставить приоритеты в отношении остальных частей бизнеса и включить их в стратегию ИТ, насколько позволяет время.
Даже имея в наличии стратегию ИТ, четко определяющую, какие типы проектов подлежат одобрению, комитету все равно будет непросто расставить точные приоритеты для различных проектов ИТ вследствие широкого разнообразия возможных проектов. Любые или все из приведенных ниже методов, могут быть использованы для проведения такой приоритезации:
• Метод строительного блока. Предоставляйте высокий приоритет тем проектам, которые необходимы как строительные блоки для дальнейших проектов, которые не могут быть завершены, пока не реализованы первые проекты. Например, общекорпоративная сеть должна быть завершена прежде, чем во всей компании может быть установлена система планирования производственных ресурсов.
• Портфельный метод. Когда денежные ресурсы сокращаются, компания имеет тенденцию отменять все рискованные проекты ИТ и концентрирует свои усилия только на тех, которые обеспечивают очевидную и вероятную отдачу. Однако такой подход таит в себе риск никогда не достигнуть прорывного технического преимущества. Лучше определить проекты с высокой потенциальной отдачей и выделить на них небольшую часть бюджета ИТ, даже если существует высокий риск неудачи.
• Метод конкурирующих стандартов. Если проект требует использования одного из комплектов конкурирующих отраслевых стандартов, может быть, целесообразно отложить его реализацию до тех пор, пока не прояснится, какой из стандартов будет играть доминирующую роль. В противном случае, компания может обнаружить, что инвестирует средства в технологию, экспертная база поддержки которой сокращается.
• Принудительное ранжирование. Последовательно сравнивают ценность каждого проекта с каждым другим предложенным проектом для того, чтобы создать ранжирование. Например, проект А сравнивается со всеми другими предложенными проектами. Если комитет считает, что он должен иметь самый высокий приоритет, то ему присуждают этот ранг. Затем комитет индивидуально сравнивает все остальные проекты, чтобы определить следующий самый важный проект. После того, как на основе данного метода расставлены все приоритеты, комитет возвращается к списку еще раз и сравнивает каждый проект в нем со следующим сразу за ним, и повторяет этот процесс до тех пор, пока не будет удовлетворен ранжированием.
• Метод отдачи. Каждое проектное предложение должно сопровождаться расчетом экономической эффективности. Хотя комитет может проигнорировать эту информацию в интересах долгосрочной стратегии, способность проекта ИТ создавать прибыль, особенно при ранжировании среди краткосрочных проектов, не следует игнорировать.
Из только что описанных методов приоритезации, следует уделить особое внимание методу принудительного ранжирования, но в рамках более широкой схемы конкретных стратегий бизнеса. Например, если крупный скачок продаж за счет использования более эффективного персонала с мобильной связью рассматривается как основная стратегия бизнеса, то все ключевые проекты, относящиеся к этой стратегии, могут получить более высокий ранг, чем те, которые относятся к следующей наиболее важной стратегии. После этого может быть использовано ранжирование методом строительного блока, чтобы определить первоначальную приоритетность проектов внутри каждой группы проектов, а принудительное ранжирование может быть затем проведено в отношении остальных проектов.
На всем протяжении процесса определения стратегии ИТ, проведения анализа разрыва с конкурентами и установления приоритетности конкретных проектов, рабочий комитет должен помнить о необходимости детального информирования о своей деятельности правления, отдела ИТ и компании в целом. Это необходимо, чтобы обеспечить наивысший уровень поддержки и сотрудничества всех сторон, когда настанет время реализовывать пакет проектов, которые рабочий комитет рекомендует правлению.
Технические стратегии
Основной темой этой главы является разработка списка проектов ИТ, которые будут содействовать общей стратегии бизнеса компании. Однако и сам отдел ИТ, вероятно, имеет какие-то идеи относительно базовой структуры систем ИТ, которые будут использоваться. Это технические вопросы, в которых финансовый директор, скорее всего, не разбирается, поэтому следующие несколько пунктов следует иметь в виду при обсуждении технических стратегий с персоналом ИТ:
• Используйте расширяемые компоненты. Если у компании есть какие-либо перспективы расширения, то она, в конечном счете, столкнется с риском перерастания своей существующей компьютерной инфраструктуры. Поэтому финансовый директор должен поинтересоваться о возможности повышения мощности любых новых систем, которые персонал ИТ хочет установить. Действительно расширяемая система должна легко справляться со значительно большим объемом транзакций или, по крайней мере, делать это посредством логического наращивания мощности.
• Используйте открытые стандарты. Финансовый директор должен избегать использования частных систем всегда, когда это возможно, поскольку эти системы привязаны к судьбам их поставщиков. Кроме того, они обычно более дорогие, чем открытые системы, и привлекают меньшее количество независимых разработчиков, предоставляющих дополнительные услуги. Так как эти системы являются долговременными и иногда дорогостоящими, то их внедрение должно рассматриваться наряду с другими задачами. Также необходимо определить степень их влияния на деятельность компании в целом.
• Используйте одну и ту же архитектуру как можно дольше. Несмотря на предыдущую рекомендацию переключиться на открытые системы, финансовый директор сталкивается также с проблемой удержания инвестиций в ИТ на разумно низком уровне. Один из методов состоит в том, чтобы заставить отдел ИТ продлить использование существующих стандартов как можно дольше. Как только архитектура меняется, возникает шлейф связанных расходов, таких как обучение, программное обеспечение и компьютерное оборудование, поэтому финансовый директор должен заставить персонал ИТ тщательно анализировать вероятный срок жизни любой архитектуры ИТ, которую он хочет применить.
• Используйте готовое программное обеспечение. Многие компании болеют синдромом «не изобретено здесь» и предпочитают спускать крупные суммы денег на доработку систем ИТ, которые могут быть куплены у поставщика. Преимущество фабричной системы состоит в ее более низкой стоимости, поддержке поставщиком и сравнительном отсутствии сбоев (поскольку ее проверяют многие покупатели, которые направляют свои замечания поставщику). Готовые программы не следует использовать только в том случае, если будущее применение является настолько специфичным для данной компании, что фабричных решений не имеется.
• Используйте объектное программирование. Когда должно быть использовано собственное программирование, финансовому директору следует подчеркнуть важность объектного программирования (object-oriented programming), которое позволяет легко переместить блоки кодировок в различные применения и опять связать их вместе. Этот подход значительно сокращает объем текущего программирования в будущем.
• Используйте немного поставщиков. Поставщики ИТ любят сваливать вину за неисправность системы на других поставщиков. Очевидным решением является концентрация закупок ИТ на возможно меньшем числе поставщиков. Другой причиной использования немногих поставщиков является то, что крупные покупки могут привести к скидкам. Если нет способа избежать большого количества поставщиков, то финансовому директору следует, по крайней мере, назначить ведущего поставщика, по отношению к которому другие действуют как субподрядчики, который отвечает за решение возникающих в системе проблем.
• Используйте связанные базы данных. Наиболее эффективным методом хранения информации является связанная база данных (relational database), представляющая собой набор отдельных таблиц, связанных индексными полями. Таким образом, информация может быть легко обобщена и извлечена без хранения одних и тех же данных во многих местах. Использование связанной базы данных позволяет компании сохранять конкретную единицу информации только один раз, что значительно облегчает ее обновление и поддержание.
• Централизуйте только самую важную информацию. Хранилища информации обычно представляются как прекрасный способ централизации и организации всей ключевой информации компании, но при этом они дороги и трудоемки в создании и эксплуатации. Поэтому финансовому директору следует внимательно проанализировать необходимость хранения различных видов информации на этом складе, а также полные затраты на это, и сохранять только те наименования информации, по которым просматривается явная выгода.
Существует много других соображений, касающихся разработки технической стратегии, но они выходят далеко за рамки данной книги. Выделенные выше пункты наиболее полезны финансовому директору как основные ориентиры, которые необходимо учитывать при обсуждении вопросов технической стратегии с отделом ИТ.
• Используйте расширяемые компоненты. Если у компании есть какие-либо перспективы расширения, то она, в конечном счете, столкнется с риском перерастания своей существующей компьютерной инфраструктуры. Поэтому финансовый директор должен поинтересоваться о возможности повышения мощности любых новых систем, которые персонал ИТ хочет установить. Действительно расширяемая система должна легко справляться со значительно большим объемом транзакций или, по крайней мере, делать это посредством логического наращивания мощности.
• Используйте открытые стандарты. Финансовый директор должен избегать использования частных систем всегда, когда это возможно, поскольку эти системы привязаны к судьбам их поставщиков. Кроме того, они обычно более дорогие, чем открытые системы, и привлекают меньшее количество независимых разработчиков, предоставляющих дополнительные услуги. Так как эти системы являются долговременными и иногда дорогостоящими, то их внедрение должно рассматриваться наряду с другими задачами. Также необходимо определить степень их влияния на деятельность компании в целом.
• Используйте одну и ту же архитектуру как можно дольше. Несмотря на предыдущую рекомендацию переключиться на открытые системы, финансовый директор сталкивается также с проблемой удержания инвестиций в ИТ на разумно низком уровне. Один из методов состоит в том, чтобы заставить отдел ИТ продлить использование существующих стандартов как можно дольше. Как только архитектура меняется, возникает шлейф связанных расходов, таких как обучение, программное обеспечение и компьютерное оборудование, поэтому финансовый директор должен заставить персонал ИТ тщательно анализировать вероятный срок жизни любой архитектуры ИТ, которую он хочет применить.
• Используйте готовое программное обеспечение. Многие компании болеют синдромом «не изобретено здесь» и предпочитают спускать крупные суммы денег на доработку систем ИТ, которые могут быть куплены у поставщика. Преимущество фабричной системы состоит в ее более низкой стоимости, поддержке поставщиком и сравнительном отсутствии сбоев (поскольку ее проверяют многие покупатели, которые направляют свои замечания поставщику). Готовые программы не следует использовать только в том случае, если будущее применение является настолько специфичным для данной компании, что фабричных решений не имеется.
• Используйте объектное программирование. Когда должно быть использовано собственное программирование, финансовому директору следует подчеркнуть важность объектного программирования (object-oriented programming), которое позволяет легко переместить блоки кодировок в различные применения и опять связать их вместе. Этот подход значительно сокращает объем текущего программирования в будущем.
• Используйте немного поставщиков. Поставщики ИТ любят сваливать вину за неисправность системы на других поставщиков. Очевидным решением является концентрация закупок ИТ на возможно меньшем числе поставщиков. Другой причиной использования немногих поставщиков является то, что крупные покупки могут привести к скидкам. Если нет способа избежать большого количества поставщиков, то финансовому директору следует, по крайней мере, назначить ведущего поставщика, по отношению к которому другие действуют как субподрядчики, который отвечает за решение возникающих в системе проблем.
• Используйте связанные базы данных. Наиболее эффективным методом хранения информации является связанная база данных (relational database), представляющая собой набор отдельных таблиц, связанных индексными полями. Таким образом, информация может быть легко обобщена и извлечена без хранения одних и тех же данных во многих местах. Использование связанной базы данных позволяет компании сохранять конкретную единицу информации только один раз, что значительно облегчает ее обновление и поддержание.
• Централизуйте только самую важную информацию. Хранилища информации обычно представляются как прекрасный способ централизации и организации всей ключевой информации компании, но при этом они дороги и трудоемки в создании и эксплуатации. Поэтому финансовому директору следует внимательно проанализировать необходимость хранения различных видов информации на этом складе, а также полные затраты на это, и сохранять только те наименования информации, по которым просматривается явная выгода.
Существует много других соображений, касающихся разработки технической стратегии, но они выходят далеко за рамки данной книги. Выделенные выше пункты наиболее полезны финансовому директору как основные ориентиры, которые необходимо учитывать при обсуждении вопросов технической стратегии с отделом ИТ.
Конкретное применение
До сих пор мы рассматривали общую схему, которой финансовому директору следует придерживаться при разработке стратегии ИТ. Однако остается вопрос: какие конкретные направления ИТ являются наиболее важными для компании, следующей определенным стратегическим курсом? У каждой компании обстоятельства будут весьма различными, но при указанных ниже стратегиях пригодится следующий перечень направлений работы:
• Стратегия взрывного роста продаж. В данном случае компания решила наращивать продажи максимально возможным темпом, игнорируя эффективность затрат, совершенствование продукции или другие параметры производственной эффективности в краткосрочном плане. Ей следует подумать об установке компьютерных систем для своих дилеров и торговых представителей, дающей им прямой доступ к базе данных компании о ценах и исполнении заказов. Она может обеспечить мобильный доступ для менеджеров по продажам, чтобы они могли лучше оценивать информацию прямо с мест. Она может также создать котировальную систему для сбытовиков, которая отслеживает, какие котировки находятся в стадии разработки, какие были выставлены и какие заказы выиграли, а также причины проигранных заявок. Высшее руководство пожелает иметь ежедневный доступ к информации о продажах. Кроме того, стратегия может включать полную стандартизацию систем, устанавливаемых во всех новых местах деятельности для того, чтобы сократить для персонала ИТ объем работ, связанных с их обслуживанием. Как правило, компании следует предусмотреть установку готового программного обеспечения «Управление отношениями с клиентами» (customer relationship management, CRM) для использования ее торговым персоналом, чтобы иметь централизованную базу данных по клиентской информации.
• Стратегия отличного обслуживания клиентов. В этом случае компания предпочитает прилагать дополнительные усилия для обеспечения первоклассного обслуживания своих клиентов, вероятно, сопровождающегося более высокой ценой товаров, которую покупатели готовы платить в обмен за этот сервис. Ей следует подумать о предоставлении своим клиентам электронного доступа к информации об их заказах, возможно, через сеть Интернет. Она также должна позволить им делать электронные заказы либо через Интернет, либо посредством сети электронного обмена информацией (electronic data interchange, EDI). Далее, если компьютерный доступ невозможен, она должна рассмотреть возможность установки автоответчика для получения той же информации по телефону. Кроме того, должны иметься внутренние базы данных для отслеживания работы с жалобами клиентов, а также проблем с качеством товаров или услуг и состояния всех заказов на обслуживание на месте. Эти системы могут быть также объединены с глобальными системами слежения и, таким образом, клиенты могут видеть, где именно находятся их грузы по всему миру. Руководство компании должно иметь непосредственный доступ к этим базам данных, чтобы видеть, где возникают проблемы; этот подход может быть усовершенствован до «сигнальной» технологии, когда система автоматически извещает руководство о возникающей проблеме. Компании следует также иметь в наличии систему отзыва товара, возможно, включающую отслеживание произведенных партий, с тем, чтобы проблемы с продукцией можно было урегулировать быстро и эффективно. Кроме того, система должна иметь связь между поступлением заказа и системами заказывания или производства запасных частей, чтобы обязательства по поставке можно было исполнять автоматически и в режиме онлайн, с доступом к этой информации со стороны клиентов.
• Стратегия совершенствования продукции. В этом случае компания хочет постоянно совершенствовать свои изделия и разрабатывать новые, исходя из предпосылки, что покупатели будут платить за них более высокую цену. Ей следует предусмотреть установку систем, которые позволят легко обмениваться чертежами и другой проектной документацией в электронном виде с ее деловыми партнерами. Она может также установить системы управления проектами, обеспечивающие возможность параллельной работы над новым изделием нескольких подразделений. Далее, системы должны давать возможность руководству рассчитывать время выхода на рынок с каждым разрабатываемым изделием, а также видеть проблемы на стадии разработки. Также должна иметься база данных по стоимости компонентов изделия, хранящая информацию о стоимости различных модификаций изделия при разных объемах закупок или производства, которая полезна для выхода на целевой уровень себестоимости. Кроме того, следует иметь передовые системы калькуляции затрат для расчета издержек на любой стадии процесса разработки. Быстрой разработке и испытаниям моделей изделий должна способствовать также система создания прототипов. Наконец, могут потребоваться системы для отслеживания всех этапов прохождения патентных заявок, а также лицензионных соглашений по продукту с другими компаниями.
• Стратегия взрывного роста продаж. В данном случае компания решила наращивать продажи максимально возможным темпом, игнорируя эффективность затрат, совершенствование продукции или другие параметры производственной эффективности в краткосрочном плане. Ей следует подумать об установке компьютерных систем для своих дилеров и торговых представителей, дающей им прямой доступ к базе данных компании о ценах и исполнении заказов. Она может обеспечить мобильный доступ для менеджеров по продажам, чтобы они могли лучше оценивать информацию прямо с мест. Она может также создать котировальную систему для сбытовиков, которая отслеживает, какие котировки находятся в стадии разработки, какие были выставлены и какие заказы выиграли, а также причины проигранных заявок. Высшее руководство пожелает иметь ежедневный доступ к информации о продажах. Кроме того, стратегия может включать полную стандартизацию систем, устанавливаемых во всех новых местах деятельности для того, чтобы сократить для персонала ИТ объем работ, связанных с их обслуживанием. Как правило, компании следует предусмотреть установку готового программного обеспечения «Управление отношениями с клиентами» (customer relationship management, CRM) для использования ее торговым персоналом, чтобы иметь централизованную базу данных по клиентской информации.
• Стратегия отличного обслуживания клиентов. В этом случае компания предпочитает прилагать дополнительные усилия для обеспечения первоклассного обслуживания своих клиентов, вероятно, сопровождающегося более высокой ценой товаров, которую покупатели готовы платить в обмен за этот сервис. Ей следует подумать о предоставлении своим клиентам электронного доступа к информации об их заказах, возможно, через сеть Интернет. Она также должна позволить им делать электронные заказы либо через Интернет, либо посредством сети электронного обмена информацией (electronic data interchange, EDI). Далее, если компьютерный доступ невозможен, она должна рассмотреть возможность установки автоответчика для получения той же информации по телефону. Кроме того, должны иметься внутренние базы данных для отслеживания работы с жалобами клиентов, а также проблем с качеством товаров или услуг и состояния всех заказов на обслуживание на месте. Эти системы могут быть также объединены с глобальными системами слежения и, таким образом, клиенты могут видеть, где именно находятся их грузы по всему миру. Руководство компании должно иметь непосредственный доступ к этим базам данных, чтобы видеть, где возникают проблемы; этот подход может быть усовершенствован до «сигнальной» технологии, когда система автоматически извещает руководство о возникающей проблеме. Компании следует также иметь в наличии систему отзыва товара, возможно, включающую отслеживание произведенных партий, с тем, чтобы проблемы с продукцией можно было урегулировать быстро и эффективно. Кроме того, система должна иметь связь между поступлением заказа и системами заказывания или производства запасных частей, чтобы обязательства по поставке можно было исполнять автоматически и в режиме онлайн, с доступом к этой информации со стороны клиентов.
• Стратегия совершенствования продукции. В этом случае компания хочет постоянно совершенствовать свои изделия и разрабатывать новые, исходя из предпосылки, что покупатели будут платить за них более высокую цену. Ей следует предусмотреть установку систем, которые позволят легко обмениваться чертежами и другой проектной документацией в электронном виде с ее деловыми партнерами. Она может также установить системы управления проектами, обеспечивающие возможность параллельной работы над новым изделием нескольких подразделений. Далее, системы должны давать возможность руководству рассчитывать время выхода на рынок с каждым разрабатываемым изделием, а также видеть проблемы на стадии разработки. Также должна иметься база данных по стоимости компонентов изделия, хранящая информацию о стоимости различных модификаций изделия при разных объемах закупок или производства, которая полезна для выхода на целевой уровень себестоимости. Кроме того, следует иметь передовые системы калькуляции затрат для расчета издержек на любой стадии процесса разработки. Быстрой разработке и испытаниям моделей изделий должна способствовать также система создания прототипов. Наконец, могут потребоваться системы для отслеживания всех этапов прохождения патентных заявок, а также лицензионных соглашений по продукту с другими компаниями.