Текст книги "Настольная книга финансового директора"

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

Компания должна платить в федеральный фонд занятости, если она заплатила служащим по крайней мере 1500 долл. в любой календарный квартал, или имела по меньшей мере одного служащего в течение некоторой части дня в пределах по крайней мере 20 недель года. Короче, почти все компании будут обязаны перечислять федеральные налоги на безработицу. В 2001 календарном году ставка налога составляла 6,2 % на первые 7000 долл., выплаченных каждому служащему. Это ведет к концентрации большей части перечислений федерального налога на безработицу в первом квартале календарного года. Во многих штатах можно зачесть федеральный налог на безработицу в размере до 5,4 % облагаемого фонда оплаты труда, что дает в результате чистый федеральный налог на безработицу всего в 0,8 %.

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

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

Глава 4
Стратегия в области информационных технологий

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

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

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

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

• Когда существует переизбыток заявок на проекты ИТ. Это одна из наиболее типичных причин разработки стратегии ИТ. Менеджер ИТ совершенно завален количеством заявок, поступающих в его отдел, и просит начальство о помощи в разборе этих заявок. В таком случае используется такая стратегия ИТ, которая выступает как сортировочный механизм для отбора самых необходимых проектов.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Метод отдачи. Каждое проектное предложение должно сопровождаться расчетом экономической эффективности. Хотя комитет может проигнорировать эту информацию в интересах долгосрочной стратегии, способность проекта ИТ создавать прибыль, особенно при ранжировании среди краткосрочных проектов, не следует игнорировать.

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

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

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

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

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

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

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

• Используйте объектное программирование. Когда должно быть использовано собственное программирование, финансовому директору следует подчеркнуть важность объектного программирования (object-oriented programming), которое позволяет легко переместить блоки кодировок в различные применения и опять связать их вместе. Этот подход значительно сокращает объем текущего программирования в будущем.

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

• Используйте связанные базы данных. Наиболее эффективным методом хранения информации является связанная база данных (relational database), представляющая собой набор отдельных таблиц, связанных индексными полями. Таким образом, информация может быть легко обобщена и извлечена без хранения одних и тех же данных во многих местах. Использование связанной базы данных позволяет компании сохранять конкретную единицу информации только один раз, что значительно облегчает ее обновление и поддержание.

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

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