Информационное общество. Определение, основные черты

Вид материала

Документы

Содержание План внедрения, финансовый анализ, переговоры Рабочие задачи. Последовательности и зависимости. Расписание и длительность выполнения задач. Планы перевода персонала на новую систему. Экономическая переоценка проекта 1. Новое представление о затратах на оплату труда 3. Предварительная оценка необходимого аппаратного и сопутствующего программного обеспечения. Стоимость проекта. Стоимость поддержки. Дополнительные издержки. Ускорение амортизации. Пункт переговоров Тактика ведения переговоров Принцип № 2. О стоимости каждой позиции надо договариваться отдельно. Принцип № 3. Не доводи подход «все из одних рук» до абсурда. Принцип № 4. Используй уступки. Принцип № 5. Плохой и хороший. Принцип № 6. Подгадай время. Принцип № 7. Держи в поле зрения по крайней мере двух вендоров. ... Полное содержание

Подобный материал:

• Информационное общество Информационное общество, 118.42kb.
• 1. Определение и основные характеристики информационного общества, 575.54kb.
• История и современность, №2, сентябрь 2009, 398.1kb.
• Лекция: Информационное обеспечение ис: Информационное обеспечение ис. Внемашинное информационное, 314.22kb.
• Распоряжение от 20 октября 2010 г. N 1815-р о государственной программе российской, 2080.19kb.
• Распоряжение от 20 октября 2010 г. N 1815-р о государственной программе российской, 2442.12kb.
• Вопросы к экзамену по Отечественной истории, 34.96kb.
• Обществознание интенсивный курс Авторы: Александрова И. Ю., Андреева В. В., Глазунова, 1095.61kb.
• Экономический факультет рудн, 147.41kb.
• Информатизация образования и модернизация школы, 313.71kb.

План внедрения, финансовый анализ, переговоры⁴

План внедрения

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

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

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

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

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

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

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

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

Экономическая переоценка проекта

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

1. Новое представление о затратах на оплату труда приглашенных и внутренних специалистов вместе с оценкой количества и их почасовой стоимости.

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

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

В результате экономического анализа команда менеджеров по выбору вендора должна вывести следующие параметры проекта.

Стоимость проекта. Общая стоимость приобретения всех необходимых технических компонентов, стоимость их полной конфигурации, настройки, интеграции, внедрения, обучения персонала и ввода системы в действие — все на основе предварительного плана проекта.

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

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

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

Экономический анализ также должен быть основан на разбитии стоимости проекта на традиционные категории: аппаратное, программное обеспечение, сотрудники а также возможные отклонения от первоначальной оценки затрат после внедрения проекта. Конкретные суммы и всевозможные детали должны быть обсуждены совместно с финансовым отделом или CFO. Экономический анализ может быть упрощен за счет введения допущений там, где есть недостаток информации. После того как проект и постоянные затраты вновь оценены, команда может пересчитать ROI проекта, время, в течение которого проект окупится, и другие аналогичные метрики.

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


Обрати внимание:

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

Переговоры

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

Цикл и задачи некоторых пунктов переговоров с вендорами

Пункт переговоров	Цели и задачи
Лицензирование	Естественно, нужно получить насколько можно низкие цены на все что можно. Типичные размеры скидок находятся в пределах от 10 до 30%. Кроме того, надо пытаться максимально оттянуть окончательные выплаты по проекту. В типичном случае при подписании платится 50% стоимости договора. Лучше, если часть выплат происходит по прошествии по крайней мере 90 дней после запуска системы.

Скидки на будущие покупки	На стадии подписания договора и выплаты первого взноса у покупателя больше всего возможностей выторговать что-то еще. Значит, именно в это время должны быть оговорены уровни скидок на потенциальные покупки в будущем.
Уровни сервиса и поддержки	Надо понять, как устроена иерархия сервиса вендора. Как правило, она состоит из "серебряного", "золотого" и "платинового" уровней. Если переход из одной категории в другую предполагает определенные выплаты, надо попытаться договориться, чтобы это было бесплатно.
Услуги консультантов	Вендоры, как правило, подталкивают покупателей к включению в контракт определенных услуг консультантов, чтобы быть уверенным в том, что инсталляция решения проходит успешно. Если необходимо дать какие-то обязательства по этому вопросу, надо принимать уровень обязательств настолько низкий, насколько это возможно. Его всегда можно в дальнейшем увеличить. При этом лучше предварительно договориться о цене на услуги консультантов как на текущий период, так и на будущее, пока контракт еще окончательно не подписан. Цену на услуги консультантов желательно зафиксировать в контракте.
Обучение	Типичная структура цен на обучение зависит от цены на одного обучающегося. Поэтому вендоры пытаются связать скидки на обучение с количеством обучающихся. Но опыт показывает, что затраты на обучение можно снизить как минимум на 10%, независимо от количества участников. Эффективный способ управлять стоимостью расходов на обучение — подготовка собственного инструктора по технологии вендора и эту возможность тоже надо согласовать.
Будущее обучение	Желательно договориться о скидке на все будущие обучения на стадии переговоров с вендором, пока контракт еще не подписан.
Стоимость поддержки — первый год	Этот компонент может заметно влиять на общую стоимость проекта. Как правило, стоимость поддержки в первый год может составлять от 8 до 30% стоимости лицензий. Здесь надо договориться, чтобы стоимость поддержки базировалась на проценте от цены со скидкой, а не от прейскурантной.
Ежегодная поддержка	Тут тоже можно попробовать сэкономить. Ключ в том, чтобы понять, какая цена является базовой для определения процента, затрачиваемого на ежегодную поддержку после первого года, — стоимость лицензий или общая цена услуг за год.

Тактика ведения переговоров

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

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

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

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

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

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

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

Принцип № 8. Никогда не вноси предоплату за поддержку. Иногда вендоры предлагают скидки в случае, если заказчиками вносится предоплата за поддержку ИТ-системы. На эту уловку ни в коем случае нельзя идти, так как ИТ-менеджер теряет возможность влияния на вендора. Риск потери предоплаты, как правило, гораздо выше, чем процент, выигранный на скидке.

Принцип № 9. Знай, когда «раствориться». Если переговоры заходят в тупик, то один из приемов — уйти в тень, затаиться — под любым предлогом временно не отвечать на письма и телефонные звонки менеджеров вендора. Время на стороне покупателя, и недостаток информации будет оказывать давление на вендора, может дать ощущение, что покупатель «ускользает», а это даст дополнительные преимущества.

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

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


10 принципов успешных переговоров с вендором

№ 1. Будь уверен.

№ 2. О стоимости каждого позиции надо договариваться отдельно.

№ 3. Не доводи принцип «все из одних рук» до абсурда.

№ 4. Используй уступки.

№ 5. Плохой и хороший.

№ 6. Подгадай время.

№ 7. Держи в поле зрения по крайней мере двух вендоров.

№ 8. Никогда не вноси предоплату за поддержку.

№ 9. Знай когда «раствориться».

№ 10. Последняя уступка.


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


ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО ОБРАЗОВАНИЮ




РОСТОВСКИЙ ГОСУДАРСТВЕННЫЙ ЭКОНОМИЧЕСКИЙ УНИВЕРСИТЕТ «РИНХ»


Долженко А.И., Тимченко Н.А.


ИНФОРМАЦИОННЫЙ МЕНЕДЖМЕНТ.

Моделирование бизнес-процессов


Методические рекомендации по выполнению лабораторных работ


Ростов-на-Дону, 2006


УДК 004.4 (075)

Д


Долженко А.И., Тимченко Н.А. Информационный менеджмент. Моделирование бизнес-процессов: Лабораторный практикум/ РГЭУ «РИНХ» - Ростов-н/Д., 2006. – 102с. - ISBN 5–7972–


В лабораторном практикуме приведены необходимые теоретические сведения и примеры моделирования бизнес-процессов с использованием структурного подхода при проектировании информационных систем, базирующегося на стандартах IDEF0, DFD и IDEF3. Лабораторные работы охватывают основные этапы описания бизнес-процессов и реинжиниринга бизнес-процессов.

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


Рецензенты: Ефимов Е.Н., Щербаков С.М.


Утверждён в качестве лабораторного практикума редакционно-издательским советом Ростовского государственного экономического университета.


ISBN  - РГЭУ «РИНХ», 2006

 - Долженко А.И., 2006

 - Тимченко Н.А. 2006

СОДЕРЖАНИЕ