Бизнес правила программного продукта

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

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

Внедрение программного продукта с точки зрения бизнес-консультанта.

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

Oracle Policy Automation и создание простого бизнес-правила

У вас нет какой-то заинтересованности в том, чтобы продать какой-то продукт. Более того, вы его не продаете в принципе. Клиент покупает выбранное вами программное обеспечение не у вас, а у разработчика. А потому, если новое программное обеспечение будет просто выполнять такие же функции, что и старое, свою задачу вы не выполнили. Вы внедряете такое программное обеспечение, которое будет:

• Эффективно решать те задачи, которые поставил перед вами клиент.
• Поможет вам найти решение проблем, которые возникли в бизнесе.

1. Получили перечень задач, которые нужно реализовать.
2. Доработали программный продукт с учетом пожеланий клиента.
3. Установили везде программу, настроили.
4. Провели краткое обучение.
5. Оставили инструкцию, написанную техническим языком и понятную, чаще всего, только системному администратору.

Именно такой вариант работы я не единожды наблюдал лично, во время работы в компаниях-партнерах 1С. Кроме того, многие мои клиенты-бизнесмены, столкнувшиеся с внедрением различных программных продуктов, также рассказывали именно о таком варианте. Максимум формального подхода – минимум результативности. Что в итоге?

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

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

Введение в управление бизнес-процессами

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

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

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

Что такое внедрение?

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

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

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

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

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

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

Ошибки при внедрении.

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

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

Если вы будете ограничены строгими временными рамками, это может привести к спешке. А в результате – к большому числу ошибок и недоработок. Цель должна быть обозначена «в общем». Не нужно загонять себя в какие-то жесткие рамки, не нужно указывать жестко перечень доработок от и до. Вы – бизнес-консультант, ваша задача – решить проблемы в бизнесе.

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

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

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

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

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

А потому и предсказать точно, к чему вы с клиентом придете в финале, и сколько времени займет работа, невозможно. В зависимости от сложности и объема предстоящей работы я чаще всего называю какие-то примерные сроки. Это могут быть 2 – 4 месяца или от полугода до 1,5 лет.

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

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

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

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

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

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

Кроме того, помните, что внедрение нового программного продукта, скорей всего, в его компании проводилось достаточно давно. Малый и средний бизнес очень часто пользуется одним программным обеспечением 7 – 10 лет. А потому к моменту начала вашей работы сотрудники компании либо уже забыли, как происходит внедрение программ, либо никогда не участвовали в этом процессе.

А потому нужно понимать, что вы можете столкнуться со страхами, с неприятием, с другими сложностями. Приведу пример. Когда-то я и сам слишком углублялся в технические нюансы и пытался пояснять чем, скажем, MailChimp отличается от 1С рассылки. Я рассказывал об API, о статистике, о числе отказов, а также о других технических параметрах.

При этом клиенту, на самом деле, нужны были совсем другие данные. Ему было достаточно продемонстрировать пример письма и показать пример статистики, чтобы мы поняли друг друга и клиент понял выгоду для себя. Говорите с клиентом с его точки зрения и на его языке!

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

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

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

Источник: erbica.ru

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

Модель организационной структуры предприятия представ­ляет собой традиционную иерархическую структуру подчине­ния подразделений и персонала (организационных единиц). На­значение моделирования организационной структуры приме­нительно к информационной системе заключается в распреде­лении автоматизируемых функций по работникам подразделе­ний и определении полномочий доступа к информационной системе.

Бизнес-правила — это специальные сведения, которые хранятся в репозитории и используются для контроля корректности построенной модели предприятия и про­цессов конфигурации и эксплуатации ИС. В системе R/3 биз­нес-правила встроены в бизнес-объекты, в системе BAAN биз­нес-правила выделены в самостоятельные компоненты.

Рассмотрим реализацию модельно-ориентированного проектиро­вания ИС.

В силу сложности комплексной типовой информационной системы для модельно-ориентированного проектирования харак­терны следующие особенности.

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

• Консультанты со стороны фирмы-производителя программ­ного продукта принимают участие на всех этапах внедрения системы и особенно на этапе анализа требований.

• Возрастает роль руководства предприятия в организации и контроле за созданием информационной системы.

В известных методологиях модельно-ориентированного про­ектирования ИС Accelerated SAP и BAAN Orgware большое внимание уделяется регламентации последовательности опера­ций на основе применения программных средств планирования, позволяющих ускорить процесс внедрения типовой ЭИС.

Техно­логия модельно-ориентированного проектирования ИС вклю­чает четыре основные стадии:

– выбор типового проекта,

– разра­ботка проектной модели предприятия,

– ввод в эксплуатацию и поддержка функционирования.

На всех стадиях используется инструментарий моделирова­ния предприятия.

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

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

На стадии построения предварительной модели предприятия строятся модели:

После завершения этапа построения предварительной моде­ли предприятия руководство предприятия принимает решение о выборе типовой информационной системы, модель предприятия которой в наибольшей степени соответствует целям автоматиза­ции.

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

На стадии «Разработка проектной модели предприятия» производится привязка модели предприятия к функционально­сти типовой ИС, на основе которой в последую­щем автоматически выполняется конфигурация информационной системы.

На стадии разработки проектной модели предприятия выпол­няются следующие работы:

• инсталляция программного продукта, реализующего типовую ИС;

• проведение обучения проектной команды;

• привязка модели предприятия к компонентам типовой инфор­мационной системы;

• определение требований к доработке программного обеспе­чения;

• проектирование внешних интерфейсов системы.

В начале разработки проектной модели консультанты по ти­повой информационной системе совместно с проектной группой на основе предварительно построенной модели бизнес-функций и референтной модели уточняют модель бизнес-функций. Правильность выбора бизнес-функ­ций контролируется на основе использования бизнес-правил.

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

Далее производится » Привязка бизнес-объектов к программным мо­дулям «. В объектно-ориентированном представлении дан­ная операция выполняется путем задания имен методов в опре­делениях классов объектов. В функционально-ориентированном представлении для соответствующих процедур задается список входных и выходных объектов. Корректность привязки контро­лируется с помощью бизнес-правил.

Далее осуществляется привязка исполнителей процес­са к использу­емым программным модулям и бизнес-объектам. При этом устанавливаются роли испол­нителей для выполнения той или иной работы и создаются спецификации интерфейса пользователя. Корректность опе­рации проверяется также с использованием бизнес-правил.

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

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

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

Генерация пользовательских интерфейсов выполняется автоматически по модели взаимодействия исполнителей и программных модулей (опи­санию ролей пользователей).

Доработка программных модулей или разработка новых про­граммных модулей и интерфейсов осуществ­ляется на основе определенных ранее спецификаций на доработ­ку программных модулей и интерфейсов с использованием языковых средств типовой системы.

В завершении стадии реализации осуществляется комплекс­ное тестирование всех компонентов корпоративной ИС.

Стадия «Ввод в эксплуатацию» осуществляется по­этапно в соответствии с определенным планом. Перед началом эксплуатации должны быть выполнены следующие работы:

• создание документации конечных пользователей и их обучение;

• установка программно-технической среды эксплуатации ИС;

• наполнение информацией новых баз данных или подключе­ние и конвертация существующих баз данных.

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

Литература к разделу 2

1. Грекул В. И. Проектирование информационных систем / В. И. Грекул, Н. Г. Денищенко, Н. Л. Коровкина. – Интернет‑университет информационных технологий – ИНТУИТ.ру, 2005.

2. Смирнова Г. Н., Сорокин А. А., Тельнов Ю. Ф.
Проектирование экономических информационных систем. – М.: Финансы и статистика, 2002. – 512 с.

3. Павлов, А. Н. Опыт управления проектами на основе стандарта PMI PMBOK: изложение методологии и опыт применения. – М.: Бином. Лаборатория знаний, 2011. – 208 с.

4. Орлик, С. Программная инженерия //

5. SWEBOK // https://ru.wikipedia.org/wiki/SWEBOK

6. Guide to the Software Engineering Body of Knowledge: 2004 version Swebok. – Computer Society, 2004. – 202 p. (книга доступна для чтения по адресам: https://www.swebok.org и https://lib.mexmat.ru/books/11832. Переводы глав оригинального SWEBOK с замечаниями и комментариями доступны на сайте С. Орлика: https://swebok.sorlik.ru/index.html).

7. Дубова, Н. Знакомьтесь: SWEBOK // https://www.osp.ru/os/2006/07/3290839/

8. Рекомендации по преподаванию программной инженерии и информа­тики в университетах = Software Engineering 2004. Curriculum Guidelines for Undergraduate Degree Programs in Software Engineering; Computing Curricula 2001: Computer Science. – М.: ИНТУИТ.РУ «Интернет‑университет информационных технологий», 2007. – 462 с.

9. Маглинец, Ю. А. Анализ требований к автоматизированным информа­цион­ным системам. – М.: Интернет‑университет информационных технологий, БИНОМ. Лаборатория знаний, 2008. – 200 с.

10. Вигерс, К. Разработка требований к программному обеспечению. – М.: Издательско-торговый дом «Русская Редакция», 2004. – 576 с.

11. Леффингуелл, Д., Уидриг, Д. Принципы работы с требованиями к программному обеспечению. – М.: Вильямс, 2002. – 448 с.

12. Коберн, А. Современные методы описания функциональных требований к системам. – М.: Лори, 2002. – 263 с.

13. Мацяшек, Л. Анализ и проектирование информационных систем с помощью UML 2.0. – М.: Вильямс, 2008. – 816 с.

14. Орлик, С., Булуй, Ю. Программные требования (Software Requirements по SWEBOK) // https://swebok.sorlik.ru/1_software_requirements.html

15. Бизнес-требования к информационной системе //

16. IEEE Standart 830‑1998. IEEE Recommended Practice for Software Requirements Specifications.

17. Спецификация программного обеспечения //

18. Методика составления спецификаций требований к программному обеспечению (IEEE-830-1998) //

19. Халл, Э., Джексон, К., Дик, Дж. Разработка и управление требова­ниями. – М.: Telelogic, 2005. – 230 с.

20. Золотухина, Е. Б. Управление требованиями при разработке програм­мных систем с использованием Rational RequisitePro. – М.: ИНТЕРФЕЙС, 2002. – 81 с.

Понравилась статья? Добавь ее в закладку (CTRL+D) и не забудь поделиться с друзьями:

Источник: studopedia.ru

Как организовать сбыт программных продуктов: руководство для разработчиков

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

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