Алексей Чубарь: «Блокчейну нужен конкретный бизнес-заказчик». Бизнес заказчик


заказчик - это... Что такое бизнес-заказчик?

 бизнес-заказчик

 

бизнес-заказчик (ITIL Service Strategy) Получатель продуктов или услуг, предоставляемых бизнесом. Например, если бизнес – производство автомобилей, то бизнес-заказчик – тот, кто покупает автомобиль.[Словарь терминов ITIL версия 1.0, 29 июля 2011 г.]

EN

business customer(ITIL Service Strategy) A recipient of a product or a service from the business. For example, if the business is a car manufacturer, then the business customer is someone who buys a car.[Словарь терминов ITIL версия 1.0, 29 июля 2011 г.]

Тематики

  • информационные технологии в целом

Справочник технического переводчика. – Интент. 2009-2013.

  • бизнес-единица
  • бизнес-операция

Смотреть что такое "бизнес-заказчик" в других словарях:

  • Бизнес Люкс — Комплексная автоматизированная система «Бизнес Люкс»  система управления в масштабах предприятия, построенная на базе современных технологий и платформ, являющихся основой для построения информационных систем. Комплексная автоматизированная… …   Википедия

  • бизнес — Экономическая деятельность, дающая прибыль; любой вид деятельности, приносящий доход, являющийся источником обогащения. [ГОСТ Р 53114 2008] бизнес (ITIL Service Strategy) Общекорпоративное образование или организация, состоящая из некоторого… …   Справочник технического переводчика

  • Заказчик — юридическое или физическое лицо, сделавшее заказ другой стороне, изготовителю, продавцу, поставщику товаров и услуг. Словарь бизнес терминов. Академик.ру. 2001 …   Словарь бизнес-терминов

  • Бизнес-центр Терра — Значимость предмета статьи поставлена под сомнение. Пожалуйста, покажите в статье значимость её предмета, добавив в неё доказательства значимости по частным критериям значимости или, в случае если частные критерии значимости для… …   Википедия

  • Комплексная Автоматизированная Система "Бизнес Люкс" — Комплексная автоматизированная система «Бизнес Люкс»  система управления в масштабах предприятия, построенная на базе современных технологий и платформ, являющихся основой для построения информационных систем. Комплексная автоматизированная… …   Википедия

  • Девелопер — (Developer) Девелопер это предприниматель, занимающийся созданием новых объектов недвижимости или разрабатывающий стратегии развития Понятие девелопера, виды девелоперов и их деятельность, этапы деятельности крупных девелоперов при разработке… …   Энциклопедия инвестора

  • Покупатель — (Purchaser) Определение покупателя, права покупателя, покупательские критерии Инфоормация об определении покупателя, права покупателя, покупательские критерии Содержание Содержание Определение Таинственный покупатель Цели и задачи исследования… …   Энциклопедия инвестора

  • Потребитель — (Сustomer) Содержание Содержание Определение История развития института защиты прав в Источники правового регулирования в Российской Федерации Основные права приобретателя Процессуальные особенности защиты прав потребителей Споры, связанные с ФЗ… …   Энциклопедия инвестора

  • ГОСТ Р ИСО/МЭК 15504-1-2009: Информационные технологии. Оценка процессов. Часть 1. Концепция и словарь — Терминология ГОСТ Р ИСО/МЭК 15504 1 2009: Информационные технологии. Оценка процессов. Часть 1. Концепция и словарь оригинал документа: 3.31 атрибут оценки процесса (process attribute): Измеримая характеристика возможности процесса оценки,… …   Словарь-справочник терминов нормативно-технической документации

  • Software as a service — (SaaS) («Программное обеспечение как услуга»), или Software on Demand (SoD) («Программное обеспечение по требованию»)  бизнес модель продажи программного обеспечения, при которой поставщик разрабатывает веб приложение и самостоятельно… …   Википедия

technical_translator_dictionary.academic.ru

Методы сбора требований или «Как понять, что хочет заказчик?»

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

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

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

Анкетирование

Данный способ подразумевает под собой составление листа-опросника (анкеты, брифа), который может содержать открытые (требуют от опрашиваемого сформулировать его ответ) и закрытые (требуют от опрашиваемого выбрать ответ из предложенных вариантов) вопросы.

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

Самым известным примером анкетирования может быть “Бриф на разработку сайта” — анкета содержащая список основных требований и информацию о будущем сайте.

Преимущества:

  1. Высокая скорость получения результатов.
  2. Сравнительно небольшие материальные затраты.
Недостатки:
  1. Данный метод не подходит для выявления неявных требований.
  2. При составлении опросника физически невозможно учесть все необходимые вопросы.

Интервью

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

Данный способ применяется, в основном, для получения информации по какой-либо конкретной теме и/или для уточнения требований.

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

Из плюсов:

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

Автозапись

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

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

Примером такого метода может быть работа с концепцией или видением проекта (сам Заказчик любит называть это — «ТЗ»), которую он прислал вам на момент начала работ по аналитике.

Преимущество:

  • Помогает лучше понять сложные процедуры или процессы.
Недостаток:
  • Данный метод сильно зависит от опыта Заказчика, а также от его умения формулировать и выражать свои мысли.

Изучение существующей документации

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

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

Плюс:

  • Быстрое получение информации.
Минус:
  • Данный способ не применим при наличии в компании только базовых документов (или при их полном отсутствии) или, если в компании Заказчика не поддерживается актуальность документации.

Повторное использование спецификации

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

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

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

Преимущество:

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

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

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

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

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

Преимущество:

  • Быстрое получение обратной связи и информации от Заказчика.
Недостатки:
  • Достаточно высокая цена для Заказчика.
  • Затраты по времени на адаптацию сотрудника.

Работа «в поле»

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

Метод позволяет избежать проблем, связанных с трудностями стейкхолдеров в описании и выражении своих потребностей. В некоторых случаях процесс наблюдения может сопровождаться «интервьюированием» пользователей для уточнения особенностей и деталей их работы и задач. В процессе наблюдения можно так же выявить пути оптимизации бизнес процессов Заказчика.

Преимущества:

  1. Позволяет наглядно увидеть проблему и разработать наиболее оптимальный вариант ее решения.
  2. Помогает наиболее точно собрать требования, наблюдая за работой сотрудников.
Недостатки:
  1. В процессе наблюдения могут быть упущены некоторые альтернативные сценарии бизнес процесса.
  2. Трудно применим на секретных предприятиях или опасных (вредных) производствах.

Обучение

Обучение — это процесс, в котором Заказчик или любой другой человек из организации Заказчика, знающий процесс, обучает аналитика по принципу учитель — ученик.

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

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

Преимущество:

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

Мозговой штурм

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

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

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

Плюсы:

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

Совещание

Совещание — встреча, ориентированная на обсуждение конкретных вопросов, которые были определены и озвучены участникам заранее.

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

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

Плюсы:

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

Use case

Use cases или варианты использования позволяют собрать и сформировать функциональные требования от лица участников Диаграммы вариантов использования определяют границы решения и показывают связи с внешними системами и участниками.

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

Плюсы:

  • Позволяет проработать все варианты развития сценария (основной и альтернативные сценарии)
Минусы:
  • Метод не применим для сбора нефункциональных требований.

Эпилог

Комбинирование методик позволяет повысить эффективность сбора требований, а так же избежать их «потери». При сборе требований необходимо помнить, что важны не только функциональные требования (ЧТО делает система), но и нефункциональные (КАК система это делает).

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

Информация для статьи взята из учебного пособия по подготовке к сертификации REQB Certified Professional for Requirements Engineering (Базовый уровень).

habr.com

Best practice проектов автоматизации бизнес-процессов от профессионала. Часть 1

Андрей Кочетков – Руководитель консалтинговых проектов «Консист Бизнес Групп»*

Любой проект в консалтинговой практике, связанный с разработкой технического задания, функциональных требований или оптимизацией бизнес-процессов – задача трудоемкая, но необходимая для того, чтобы обеспечить базу комплексного проекта, свести в единую картину ожидания заказчика и прогнозируемые результаты. Руководитель консалтинговых проектов «Консист Бизнес Групп» Андрей Кочетков расскажет о том, на что следует обращать внимание, какие трудности могут возникать в проектах и как их преодолевать, поделится особенностями ведения проекта в компании diHouse – крупном оптовом дистрибуторе.

— Андрей, расскажите, пожалуйста, в целом о Ваших проектном опыте, Все ли Ваши проекты включают этап описания бизнес-процессов?

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

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

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

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

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

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

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

— Часто ли так случается, что существующие бизнес-процессы меняются при внедрении информационных систем?

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

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

— Что самое главное, что нужно учесть в работе по оптимизации бизнес-процессов?

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

— Этой модели достаточно для начала проекта автоматизации?

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

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

— Если сравнивать проекты разных заказчиков, отличаются ли клиенты друг от друга в зависимости от того, например, это государственная компания или коммерческая структура?

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

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

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

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

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

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

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

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

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

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

Продолжение темы — во второй части статьи. Здесь Вы найдете:

— Кейс проекта внедрения ИС в компании diHouse; — Работа с заказчиком: «одинаково смотрим на вещи»; — Опыт применения эффективного инструментария для подготовки ТЗ на автоматизацию.

Продолжение выйдет в ближайшее время на страницах нашего корпоративного блога.

*Справка о компании:«Консист Бизнес Групп» объединяет ведущие консалтинговые активы ГК «ЛАНИТ» и «Группа Систематика». Бизнес группа строится на базе компаний «ЛАНИТ Консалтинг», TOPS Consulting, Sciener и LC Europe и объединяет в многопрофильный ИТ-холдинг практики управленческого консалтинга, разработки, внедрения и сервисного обслуживания ИТ-решений для работы с заказчиками из ключевых отраслей российской экономики.

habr.com

заказчик - это... Что такое бизнес-заказчик?

 бизнес-заказчик
  1. business customer

 

бизнес-заказчик (ITIL Service Strategy) Получатель продуктов или услуг, предоставляемых бизнесом. Например, если бизнес – производство автомобилей, то бизнес-заказчик – тот, кто покупает автомобиль.[Словарь терминов ITIL версия 1.0, 29 июля 2011 г.]

EN

business customer(ITIL Service Strategy) A recipient of a product or a service from the business. For example, if the business is a car manufacturer, then the business customer is someone who buys a car.[Словарь терминов ITIL версия 1.0, 29 июля 2011 г.]

Тематики

  • информационные технологии в целом

EN

Русско-английский словарь нормативно-технической терминологии. academic.ru. 2015.

  • бизнес-единица
  • бизнес-отчет

Смотреть что такое "бизнес-заказчик" в других словарях:

  • бизнес-заказчик — (ITIL Service Strategy) Получатель продуктов или услуг, предоставляемых бизнесом. Например, если бизнес – производство автомобилей, то бизнес заказчик – тот, кто покупает автомобиль. [Словарь терминов ITIL версия 1.0, 29 июля 2011 г.] …   Справочник технического переводчика

  • Бизнес Люкс — Комплексная автоматизированная система «Бизнес Люкс»  система управления в масштабах предприятия, построенная на базе современных технологий и платформ, являющихся основой для построения информационных систем. Комплексная автоматизированная… …   Википедия

  • бизнес — Экономическая деятельность, дающая прибыль; любой вид деятельности, приносящий доход, являющийся источником обогащения. [ГОСТ Р 53114 2008] бизнес (ITIL Service Strategy) Общекорпоративное образование или организация, состоящая из некоторого… …   Справочник технического переводчика

  • Заказчик — юридическое или физическое лицо, сделавшее заказ другой стороне, изготовителю, продавцу, поставщику товаров и услуг. Словарь бизнес терминов. Академик.ру. 2001 …   Словарь бизнес-терминов

  • Бизнес-центр Терра — Значимость предмета статьи поставлена под сомнение. Пожалуйста, покажите в статье значимость её предмета, добавив в неё доказательства значимости по частным критериям значимости или, в случае если частные критерии значимости для… …   Википедия

  • Комплексная Автоматизированная Система "Бизнес Люкс" — Комплексная автоматизированная система «Бизнес Люкс»  система управления в масштабах предприятия, построенная на базе современных технологий и платформ, являющихся основой для построения информационных систем. Комплексная автоматизированная… …   Википедия

  • Девелопер — (Developer) Девелопер это предприниматель, занимающийся созданием новых объектов недвижимости или разрабатывающий стратегии развития Понятие девелопера, виды девелоперов и их деятельность, этапы деятельности крупных девелоперов при разработке… …   Энциклопедия инвестора

  • Покупатель — (Purchaser) Определение покупателя, права покупателя, покупательские критерии Инфоормация об определении покупателя, права покупателя, покупательские критерии Содержание Содержание Определение Таинственный покупатель Цели и задачи исследования… …   Энциклопедия инвестора

  • Потребитель — (Сustomer) Содержание Содержание Определение История развития института защиты прав в Источники правового регулирования в Российской Федерации Основные права приобретателя Процессуальные особенности защиты прав потребителей Споры, связанные с ФЗ… …   Энциклопедия инвестора

  • ГОСТ Р ИСО/МЭК 15504-1-2009: Информационные технологии. Оценка процессов. Часть 1. Концепция и словарь — Терминология ГОСТ Р ИСО/МЭК 15504 1 2009: Информационные технологии. Оценка процессов. Часть 1. Концепция и словарь оригинал документа: 3.31 атрибут оценки процесса (process attribute): Измеримая характеристика возможности процесса оценки,… …   Словарь-справочник терминов нормативно-технической документации

  • Software as a service — (SaaS) («Программное обеспечение как услуга»), или Software on Demand (SoD) («Программное обеспечение по требованию»)  бизнес модель продажи программного обеспечения, при которой поставщик разрабатывает веб приложение и самостоятельно… …   Википедия

normative_ru_en.academic.ru

«Блокчейну нужен конкретный бизнес-заказчик» — Bankir.Ru

— Блокчейн – очень горячая тема. О собственных наработках в этой области объявили несколько крупных российских банков. Есть ли у ВТБ свои проекты, в основе которых лежит применение блокчейна?

Тема не просто горячая, а перегретая

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

Для нас стратегически важной является работа Ассоциации «ФинТех», одним из учредителей которой мы являемся. В рамках ассоциации мы участвуем в создании национальной блокчейн-платформы «Мастерчейн». Ландшафт решений на блокчейне разнороден. Не секрет, что решения на Hyperledger плохо совместимы с решениями на Ethereum. Договориться на уровне банковского сообщества о выборе базовой технологии – залог того, что создаваемые решения будут применимы как для широкого круга банков, так и для широкого круга клиентов.

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

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

— Что вы думаете о перспективах блокчейна в банковском секторе?

Блокчейн – это очень хорошая технология, которая может решать конкретные задачи

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

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

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

— Из сказанного вами возникает ощущение, что у банка ВТБ нет отдельного подразделения, занимающегося исключительно блокчейном. Это так?

У нас IT и функциональные подразделения занимаются конкретными кейсами

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

— Другая горячая тема, которая обычно обсуждается в связи с блокчейном, – криптовалюты. Как вы считаете, в России нужен крипторубль?

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

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

Если будет решено, что крипторубль – это не валюта, а другой финансовый инструмент, то и регулирование будет другим.

В связи с этим возникает несколько фундаментальных сценариев. Первый – клиентский: непосредственно клиент получает возможность производить прямые расчеты со своими контрагентами. Удобно ли это клиенту? Да, безусловно. Может ли это стать единственным способом расчетов? Наверное, нет. Является ли этот инструмент наиболее технологически продвинутым? Неочевидно. Банки думают над тем, как обеспечить быстрые удобные расчеты между контрагентами. Возможно, удастся решить эту задачу, не прибегая к токенам и другим специальным инструментам.

Криптовалюта сейчас проходит этап выстраивания доверия

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

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

— А использование криптовалют в России нужно регулировать на законодательном уровне?

Нужно решить, чем является криптовалюта – товаром или финансовым инструментом

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

— Покупая криптовалюты, люди относятся к ним как к инструменту инвестирования. Сейчас много говорится о том, что с полученной таким образом прибыли нужно обязать людей платить налоги. Что вы думаете по этому поводу?

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

bankir.ru

компания заказчик - это... Что такое компания заказчик?

 компания заказчик

Labor organization: business customer

Универсальный русско-английский словарь. Академик.ру. 2011.

  • компания за столом
  • компания закрытого типа

Смотреть что такое "компания заказчик" в других словарях:

  • заказчик — 4.9 заказчик (customer): Организация или лицо, получающие продукт или услугу. Примечание 1 Заказчик может быть внутренним или внешним по отношению к организации. Примечание 2 Адаптировано из ИСО 9000:2005. Примечание 3 Другие термины,… …   Словарь-справочник терминов нормативно-технической документации

  • МиГ (компания) — ОАО «РСК «МиГ» Тип Открытое акционерное общество[1] Год основания 1939 Расположение …   Википедия

  • Потребитель — (Сustomer) Содержание Содержание Определение История развития института защиты прав в Источники правового регулирования в Российской Федерации Основные права приобретателя Процессуальные особенности защиты прав потребителей Споры, связанные с ФЗ… …   Энциклопедия инвестора

  • Покупатель — (Purchaser) Определение покупателя, права покупателя, покупательские критерии Инфоормация об определении покупателя, права покупателя, покупательские критерии Содержание Содержание Определение Таинственный покупатель Цели и задачи исследования… …   Энциклопедия инвестора

  • Занятость — (Employment) Занятость населения, виды занятости Постоянная занятость, вторичная и теневая Содержание Содержание 1. Вторичная . 2. Постоянная и нерегулярная занятость. 3. Теневая занятость, частичная и условная. Занятость населения Понятие… …   Энциклопедия инвестора

  • Международные рейтинговые агентства — (International rating agencies) Рейтинговые агентства это организация, занимающаяся оценкой платёжеспособности субъектов финансового рынка Международные рейтинговые агентства: кредитный рейтинг стран, Fitch Ratings, Moody s, S&P, Morningstar,… …   Энциклопедия инвестора

  • Каппелли, Питер — Питер Каппелли (англ. Peter Cappelli 07.09.1956) один из ведущих американских специалистов в областях человеческого капитала, управления талантами. Содержание 1 Образование 2 Достижения к настоящему моменту …   Википедия

  • Каппелли — Каппелли, Питер Питер Каппелли (англ. Peter Cappelli 07.09.1956) один из ведущих американских специалистов в областях человеческого капитала, управления талантами. Содержание 1 Образование 2 Достижения к настоящему моменту …   Википедия

  • Рейтинговые агентства — (РА) – организации, специализирующиеся на оценке кредитоспособности эмитентов и инвестиционном качестве эмитируемых ценных бумаг. По результатам своих исследований агентства присваивают кредитные рейтинги. Для того чтобы правильно использовать… …   Банковская энциклопедия

  • Премия Дом Года — Открытая общественная архитектурно строительная Премия Best Building /Дом Года (Премия Дом Года) ежегодно присуждается лучшим проектам российской архитектуры, выполненным профессиональными архитекторами и воплощенным девелоперами и строителями за …   Википедия

  • Торги — (Bidding) Торги это специфическая форма торговли, результат которой достигается посредством проведения конкурса или аукциона Информация об определении торгов, правила проведения аукционов и конкурсов, в том числе электронных торгов с… …   Энциклопедия инвестора

universal_ru_en.academic.ru

Заказчик глазами бизнес-тренера

Автор: Тимур Кармазин, к. пс. н., доцент, руководитель проекта YEX ITG, бизнес-тренер, консультантНачнем с байки. Диалог заказчика и исполнителя. - Мне не нравится! Это не то, что я хочу! - А что Вы хотите? - Хочу, чтобы нравилось!

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

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

1. эффективность инвестиций в обучение - соотношение «время-результат» в экономических показателях (Например, насколько увеличится наша прибыль после ваших занятий?)

2. наличие комплексного модульного продукта (У нас обучение рассчитано на два года. Ваши темы взаимосвязаны? Каким образом?)

3. инновационные (уникальные) тренинговые программы, их гибкая адаптация под специфику деятельности (А Вы сможете учесть специфику нашей компании? А у Вас есть новые программы?)

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

5. уникальность, состоящая в высокой практикоориентированности - инструментальный подход (А что наши сотрудники будут уметь? Смогут ли они это делать самостоятельно?)

6. внедренческий консалтинг как посттренинговое сопровождение (А Вы гарантируете результат? Вы обеспечите контроль применения полученных знаний? А Вы готовы получить вторую часть выплаты после практического результата?)

7. модерация стратегических и тактических сессий (А Вы поможете нам выработать цели (видение, ценности и т.п.))?

8. обратная оценочная информация (А Вы дадите обратную связь? Оцените наших сотрудников и команды?)

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

Ошибка 1. Отсутствие или «размытость» технического задания.

По моей практике, до 80% заказчиков тренингов не могут структурировано предоставить ТЗ. Его может не быть вообще. Оно может передаваться на словах. Оно может содержать субъективное понимание одного человека (чаще всего, ответственного за обучение). Оно может быть просто «глупым».

Какими могут быть последствия? Нельзя будет проконтролировать результат, не имея под руками образа этого результата! Нельзя будет потребовать с исполнителя или предъявить ему претензии – он «понял, как понял»! Нельзя будет интегрировать результат обучения в деятельность, поскольку «получили то, что получили»!

Ошибка 2. Перегруженность технического задания.

Пример из практики. Переговоры с потенциальным заказчиком. Слушаю 15 минут монолог о сложностях управления в компании. Понимаю, что проблема глобальная и комплексная, не факт, что решается только через обучение. Слышу запрос: «А не можете провести какое-нибудь занятие по менеджменту, чтобы наши линейные руководители не совершали таких ошибок». Шекспировский вопрос – «могу или не могу?». У меня на него ответ – не могу, ибо понимаю практическую ничтожность такого занятия. Я, как тренер, ценю свое имя – это мой бренд! Делать, зная, что сделать это невозможно – это непрофессионализм или мошенничество. Комплексная проблема решается комплексным подходом, в том числе и в обучении. Узкую проблему можно купировать «каким-нибудь занятием».

Ошибка 3. «Можете ли пошить семь шапок?»

Стандартная ситуация: надо провести тренинг - обучить технологии, например, продаж, и сформировать базовые навыки. Время - 6 академических часов («больше выделить не можем»), в группе будет 40 человек («всем надо»), «директор тоже захотел посидеть и послушать, поэтому придут еще и его заместители»…

Будем ли задавать вопрос об эффективности занятия? Сможем ли «слепить семь шапок»? Сможем! Но подход уже иной! Молодежь называет его так - «тупо заработать денег»! Вряд ли это устроит заказчика.

Ошибка 4. «Мы знаем, что это несложно»

Опять начнем с примера. Управляющая компания именитого холдинга. Запрос: «У нас этап поглощения новых компаний. Происходит взаимопроникновение организационных культур. Надо провести стратегическую сессию по актуализации компонентов философии холдинга (видение, ценности, принципы и т.п.)».

Очень сложный период в жизни любой организации! Проникновение культур – это всегда огромная управленческая проблема! То, что HR-ы понимают важность момента, говорит о их желании работать на опережение… Но, что же в запросе дальше?

«В сессии будут принимать участие 60 человек… Надо, чтобы еще это сопровождалось динамикой – людям не должно быть скучно... Еще хотим ввести компонент игры… А еще это будет 2 дня, но мы не знаем точно, сколько времени выделят, потому что еще с ними встречаются руководители… А еще это будет в другом городе… И, самое главное, это будет через 2 недели!»

Сложный ли это заказ? Очень сложный! Можно ли выполнить такой заказ? Можно, но будет нелегко! Потребует ли он значительных усилий?.. Нет, поскольку за него предлагают оплату по стоимости одного тренингового дня при проведении типового, уже подготовленного, занятия с группой не более 20 человек!

Профессионалы за такой заказ не возьмутся. Причина? «Быстро, качественно, дешево – выберите не более двух компонентов» - вот и весь ответ!

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

yex.training