Оценка ит проектов проблемы и решения реферат

Обновлено: 30.06.2024

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

Содержание

Введение …………………………………………………………………. …….3
1.Теоретические основы методов оценки эффективности ИТ ……………….4
1.1Классификация методов оценки эффективности ИТ………………………4
1.2Финансовый метод…………………………………………………………..10
1.3Качественный метод……………………………………………………. …12
1.4Вероятностный метод……………………………………………………….14
1.4.1Виды вероятностных методов…………………………………………. 16
2.Применение вероятностных методов на практике…………………………20
2.1Технология проведения проекта прикладной информационной экономики……………………………………………………………………….20
2.2Методология применения справедливой цены опционов………………..30
3.Заключение……………………………………………………………………36
Список литературы…………………………………………………………….38

Прикрепленные файлы: 1 файл

Mikhaylets_referat_po_IT.doc

Нужно добавить пример внедрения любой системы на предприятии в главу 2.

МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ

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

ФАКУЛЬТЕТ КОМЕРЦИИ И МАРКЕТИНГА

КАФЕДРА КОММЕРЦИИ И ЛОГИСТИКИ

Специальность: логистика и управление цепями поставок

Факультет: коммерции и маркетинга

Студент Михайлец Ю.В.

Руководитель работы проф.Ефимов Е.Н.

1.Теоретические основы методов оценки эффективности ИТ ……………….4

1.1Классификация методов оценки эффективности ИТ………………………4

1.4.1Виды вероятностных методов…………………………………………. 16

2.Применение вероятностных методов на практике…………………………20

2.1Технология проведения проекта прикладной информационной экономики……………………………………………………… ……………….20

2.2Методология применения справедливой цены опционов………………..30

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

На сегодняшний день проблема оценки эффективности информационных систем встает наиболее остро. В организациях различных отраслей с различной информационной интенсивностью возникает все большая зависимость бизнеса от информационных технологий. Информационные технологии и информация сегодня – это неотъемлемая и важная часть структуры бизнеса любой компании. Зависимость, ровно, как и инвестиции в информационные технологии возрастают. В среднем, в России и СНГ максимальные ИТ - бюджеты в обороте компаний составляют не более 3%, в то время как в Японии этот процент составляет около 11%, а в США около 13% .

Указанные выше цифры говорят о серьезных инвестициях в информационные технологии. Основная цель исследования эффективности информационных систем в современных компаниях – есть оценка адекватности вложенного капитала в ИТ и качественное и количественное измерение отдачи ИТ

1.Теоретические основы методов оценки эффективности ИТ.

1.1Классификация методов оценки эффективности ИТ.

Для рассмотрения оценки методов эффективности ИТ необходимо рассмотреть структуру информационной системы с точки зрения эффективности.

Рис. 1.1. ^ Структура ИС с точки зрения эффективности

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

Совокупная стоимость владения (аппаратная обеспечение, программное обеспечение, каналы связи и т.д.).
Время простоев.
Администрирование системы.
Сервисное обслуживание системы.
…..

Ограничение доступа к данным.
Обеспечение сохранности данных.
Эффективное хранение данных.
Скорость обработки одной элементарной основной бизнес - транзакции.
…

Люди (человеческий фактор):

Квалификация персонала.
Удобство работы с системой.
Наличие подсистемы поддержки принятия решения (экспертные системы).
Время использования ИС в личных целях.
…

1.2 Финансовый метод.

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

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

В этой части цикла мы сосредоточимся на финансовых методах. Их много, но чаще всего применяются три основных финансовых метода определения инвестиций в ИТ:

NPV (Net present value) - чистый приведенный доход или чистая приведенная стоимость, это зависит от формулировки.
IRR (Internal rate of return) - внутренняя норма доходности или внутренняя норма рентабельности, это тоже зависит от формулировки.
Payback - срок окупаемости инвестиций.

1.3 Качественный метод.

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

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

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

Метод информационной экономики страдает субъективизмом, особенно в части анализа рисков проекта, с другой стороны, IT Scorecard, как и BSC, требует наличия формализованной бизнес-стратегии. Для качественной оценки эффекта от инвестиций в ИТ компании применяют либо метод информационной экономики, либо IT Scorecard. И опыт показывает, что, как правило, для качественной оценки этого достаточно.

Введение
Прогресс существенно ускорил внедрение новых достижений в области информационных технологий во все сферы социально-экономической жизни общества.
Мир меняется поэтому реакция фирм должна быть быстрой. Это можно добиться оптимизацией системы управления предприятием, в том числе и c помощью информационных технологий.
Корпоративные информационные системы являются частью системыуправления предприятием. Посему и процесс внедрения корпоративной информационной системы ассоциируется с оптимизацией системы управления. Цена подобных проектов велика. Поэтому главы предприятий при принятии решения о внедрении информационной системы задаются вопросами насколько большая будет выгода и так далее.
Какая бы ни была стратегия развития предприятия, IT-стратегия должна ей соответствовать. Еслисоответствия не будет, то фирма может понести убытки. Этот значительный фактор необходимо учитывать при принятии решения о внедрении корпоративной информационной системы на предприятии.
Имеется еще один важный фактор, воздействующий на решение о внедрении корпоративной информационной системы. Это присутствие необходимых ресурсов, как материальных, так и нематериальных. Ресурсы предприятия не безграничны, и, чтобыоно имело возможность выполнять свою основную деятельность эти ресурсы необходимо разумно распределять. Отсутствие нужных ресурсов может перечеркнуть все планы по реализации проекта. Именно вследствие этого должна быть строгая увязка плана проекта не только на уровне целей и стратегии развития предприятия, но и на уровне его бюджета.
Для принятия решения о внедрении корпоративной информационнойсистемы на предприятии руководителю необходимо разобрать проект на соответствие рассмотренным выше условиям. Для этого нужна методика, дозволяющая провести такой анализ.

Методы оценки
Ныне для оценки эффективности ИТ существует несколько методов, которые можно поделить на 3 основные группы: финансовые (количественные), качественные, вероятностные.
Рисунок 1 – Методы оценки экономическойэффективности ИТ-проектов1
Среди разнообразия способов оценки эффективности информационных проектов можно выделить два основных подхода. Первый подход, традиционный, основан на оценке непосредственной (прямой) финансовой отдачи от проекта. Данный подход опирается на предположении, что практически все преимущества от внедрения информационной системы можно напрямую подсчитать. Скажем, освобождается частьрабочего времени финансового менеджера, который раньше использовал несколько дней для собирания требуемых отчетов. В следствии автоматизации этот срок может сократиться на порядок. Другой пример - в результате автоматизации процесса приемки и обработки заказов возрастает производительность труда оператора по обработке заказов.
Все улучшения, оцениваемые "напрямую", связаны с количественнымихарактеристиками автоматизируемых процессов - продолжительностью, стоимостью затрачиваемых ресурсов и пр. Финансовый менеджер, сжав срок подготовки отчетов, предоставляет более оперативную и более ценную информацию для принятия управленческих решений. А оператор по обработке заказов обрабатывает и больше и быстрее заказы. Поэтому клиент затрачивает меньшее количество времени на оформление заказа, а это уже может повыситьлояльность клиента к компании, что приводит к повторному обращению. Компания получит постоянного клиента, что дешевле, чем искать нового.
Исходя из выше перечисленного далеко не всегда существует вероятность "напрямую" оценить и представить в финансовом выражении все преимущества, которые дает нам проект автоматизации.
Для комплексной оценки эффекта от автоматизации можно использовать второй подход. Егосуть состоит в том, что производится оценка как финансовых эффектов от внедрения информационной системы - снижение стоимости и продолжительности операционных процессов, так и нефинансовой составляющей - повышение лояльности клиента, ускорение темпов вывода на рынок новых продуктов, повышение качества управленческих решений.
Важнейшая проблема.

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

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

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

Почему же могут возникать проблемы с рентабельностью продукта?

Конфликт интересов бизнеса и конечного пользователя

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

Ориентированность на функциональность в ущерб проектированию UI-интерфейсов.

Иногда возникают такие ситуации, когда бизнес не ставит в приоритет UI/UX-дизайн приложения, так как считает важным именно конечный функционал. Например, в приложении строится отчет за выбранный временной период. Однако, никто не задумывался о том, что нужно вручную с клавиатуры вводить дату в формате ДД.ММ.ГГГГ - а как же выбор из календаря?

Никому не понравится пользоваться “медленным” приложением, в котором отображение результатов на экране занимает более 5-10 сек. В данном случае, нужно проводить итерационное нагрузочное тестирование с определением планируемого количества пользователей по мере нарастания функциональности приложения, сделать код масштабируемым.

Прирост функционала приложения происходит крайне “медленно”

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

Пользователи наталкиваются на дефекты в приложении

Меня как QA-специалиста всегда особенно сильно “раздражают” баги в различных приложениях. Обычно, я всегда пишу в техподдержку с подробным описанием баг-репортов и прикладыванием скринов (а иногда даже гифок). Но рядовой пользователь этого делать не станет и просто уйдет в поисках другого приложения, оставив негативный малоинформативный отзыв. Крайне важно понимать, какие дефекты пользователь точно не должен найти. Например, в приложении Яндекс.Музыка я неоднократно сталкиваласьсталивалась с проблемой отображения двух прелоадеровпреалодеров на экране при низком уровне связи. Является ли этот баг критичным? Разумеется, нет. Но сам факт его наличия говорит о том, что пользователи с ним живут и приложение не развалилось.

Существующий аналог значительно удобнее

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

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

Приведем краткий чек-лист:

Фиксация целей, задач проекта
Определение сроков реализации проекта
Составление плана, определение необходимых ресурсов, трудозатрат
Подбор команды и компетентных специалистов
Раннее тестирование
Метрики проекта и продукта
Грамотное планирование и управление командой
Управление рисками
Сбор отзывов, анализ и улучшения продукта
Получение стабильной сборки приложения итеративно

Рассмотрим каждый пункт чек-листа подробнее на примере старта нового IT-продукта.

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

Здесь необходимо ответить на ряд вопросов:

Когда команда должна выпустить первый релиз?

Какие ресурсы необходимы для сокращения сроков?

Составление плана, определение необходимых ресурсов, трудозатрат

Какой объем работ должен быть выполнен?

Сколько сотрудников для этого нужно?

Какие технологии должны быть у них в арсенале?

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

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

Один из самых важных этапов на всем пути проекта. В данном случае, есть несколько вариантов:

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

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

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

Подключение специалиста по тестированию часто откладывается, так как считается, что если “нечего” тестировать, то зачем он нужен?

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

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

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

Приведем примеры метрик, которые помогут оценить эффективность проекта и продукта:

Time-to-market
Оценка трудозатрат (план и факт)
Оценка сроков (план и факт)
Количество пропущенных дефектов на продуктив (факт)
кол-во известных дефектов в системе, с которыми выходим в прод
Процент пере-открытых задач
Плотность дефектов по модулям
Разбивка дефектов по критичности
Соотношение новых и закрытых дефектов
Грамотное планирование и управление командой

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

Как правило, данным разделом занимается менеджер по проекту, в помощь ему выступаю тим-лиды команды, которые озвучивают возможные риски на проекте.

Сбор отзывов, анализ и улучшения продукта

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

Получение стабильной сборки приложения итеративно

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

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

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

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

Также предлагаю Вам список интересных статей по тестированию:

Факторы, которые мешают клиенту получить нужное программное решение

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

Если сделать некоторое разделение проблем при реализации IT-проектов, то можно выделить четыре наиболее яркие категории:

Технические проблемы

Здесь стоит говорить о нехватке системных ресурсов в автоматизируемой организации (или о несоответствии их требованиям программы):

Нередко в распоряжении компании-заказчика просто нет тех технических средств, которые позволили ли бы программе работать корректно. Банальная нехватка места на сервере – уже причина того, что IT-решение просто не получится использовать.

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

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

нежелание перемен со стороны сотрудников автоматизируемой компании,

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

непонимание того, что впоследствии программа будет реально помогать в работе,

страх незаменимых сотрудников стать ненужными,

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

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

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

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

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

Проблема взаимодействия компании-заказчика и разработчика

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

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

Читайте также: