Работа Бизнес-аналитик в Москве: Вакансии Бизнес-аналитик в Москве –

Работа Бизнес-аналитик в Москве: Вакансии Бизнес-аналитик в Москве - Аналитика

С чего все началось

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

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

Начнем с азов: что такое «бизнес-анализ»? Надеюсь ни для кого не секрет, что «бизнес-анализ», «анализ бизнеса» (аудит) и «бизнес-аналитика» — это совершенно разные понятия, и, кроме «похожих слов», между ними общего не так много.

Дабы не загромождать и без того объемный текст, я вынес «сборник определений» в сноску, кому интересно, можете ознакомиться.

Бизнес-Анализ? Нет, не слышал

Например, некто Howard Podeswa, в своей книге «UML for the IT Business Analyst » дает такие определения (второе издание, раздел 1, страница 1):

Существуют два вида бизнес аналитиков:
— Обычный (не IT) бизнес-аналитик – тот, кто работает в контексте бизнеса в целом. Такой специалист участвует в совершенствовании процессов, оптимизации издержек и т.д.
— Бизнес-аналитик в IT: тот, чья работа происходит в рамках отдельных IT проектов – закупки, внедрения, внесение изменений и т.д. Его задачей является взаимодействие с заинтересованными лицами со стороны заказчика (бизнес пользователи, технический персонал и т.д.) для сбора требований, исходящих от бизнеса

«International Institute of Business Analysis» (www.iiba.org) в «BABOK Guide 2.0», определяет (раздел 1.2, стр. 3):

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

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

Бизнес-аналитик, это тот, кто все это делает, безотносительно названия его должности</blockquote
Object Management Group (www.omg.org) в спецификации «BPMN 2.0» дает такое определение (стр. 499):

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

Традиционно для запада, единого определения нет, но, тем не менее, есть некие общие черты:

маяк бизнес-анализа

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

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

Бизнес аналитика

image

  • Устраняйте двусмысленные требования на самых ранних этапах

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

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

Кейс из практики: месяц разработки был потрачен на функционал переноса списка активностей из объекта №1 в объект №2. На этапе приемочного тестирования обнаружилось, что заказчик ожидал совершенно иной функционал — копирование, а не перенос активностей. В процессе переделывания функционала и детализации двусмысленности IT-команда, во-первых, договорилась с заказчиком о MVP, а, во-вторых, о необходимости работы с корнем бизнес-проблемы. Было выдвинуто предположение, что сам функционал копирования требуется только лишь по причине недостаточно качественно реализованного функционала подгрузки шаблонов активностей.

  • Не бойтесь уточнять у заказчика о целях требования


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

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

Записывайте цели вместе с заказчиком, чтобы абсолютно все участники процесса в любой момент времени понимали, зачем они выполняют свою работу.

  • Требуйте у заказчика своего присутствия на бизнес-встречах

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

Во время очной встречи руководителя подразделения с подчиненным, где мы — аналитик и UX-дизайнер — сидели «в фоне», выявился целый ряд требований, который не проявлялся в течение целого года работы команды. Мы обращали внимание на все детали: ручные записи руководителя и сотрудника, на стикеры, на пометки в windows-блокноте, на действия внутри системы. По итогу такой встречи бэклог был существенно дополнен, а мы приступили к глубокой переделке реализованного в системе функционала.

  • Старайтесь достигать соглашения и не формировать отписки
Дополнительный анализ:  Центр Аналитики и Финансовых Технологий на улице Аллея Смелых - отзывы, фото, цены, телефон и адрес - Услуги для бизнеса - Калининград -

Дает ли работа в достаточной мере сложных задач? ведь только ими и растешь.

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

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

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

Решение: Взаимодействие X и Y реализовано через веб-сервисы. Файловый обмен ведется в режиме 24/7, с момента наступления определенного события в системе Y, до полного завершения выгрузки/до наступления дедлайна/до ручной остановки процесса. Разработан формат обмена, перекрестная (между двумя системами) матрица статусов загрузок, утверждены коды возвратов.

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

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

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

Задача: обеспечить систему заказчика актуальной нормативной базой.

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

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

3. Ввести новый параметр для расчетных операций в системе.

Выполнение:

1) Определить точку «входа» параметра в Систему: вводится пользователем? Рассчитывается из других параметров (Каких? Каким образом? В какой момент времени?)?

2) Определить функции, в которых будет задействован новый параметр.

3) Для каждой функции: Проверить, влияет ли новый параметр на выполнение последующих операций, ввести параметр в формулы расчета.

4) Определить способ и место отображения параметра в интерфейсе. Нарисовать макеты.

5) Узнать, должен ли новый параметр фигурировать в выходных формах: в каких именно, каким образом.

6) На содержимое каких выходных форм этот параметр повлияет неявно? Если да, определить степень влияния, вынести вопрос на обсуждение.

7) Определить объем необходимых доработок.

8) Написать постановку задачи на разработку, либо ТЗ (в зависимости от объема доработки).

9) Протестировать результат.

Вопросы задала Эльмира Давыдова.

Кто такой бизнес-аналитик и как им стать

Кто такой бизнес-аналитик и как помогает компаниям быть на шаг впереди

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

Маркетинговые аналитики работают с BI, оптимизируют маркетинговые кампании, экономику продаж.

Финансовые аналитики разбираются в финансовых инструментах, инвестициях, кредитах и займах, условиях финансирования.

Продуктовые аналитики лучше знают метрики, связанные с конкретными продуктами, и инструменты для анализа работы эффективности продуктов (performance).

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

Посмотрим, в каких командах задействованы бизнес-аналитики и какова их роль в каждой из них.

Чаще всего бизнес-аналитики работают в консалтинговом подразделении — внутреннем отделе или в консалтинговой компании. Под консалтингом подразумеваем управленческий консалтинг, среди известных представителей которого компании McKinsey, PWC, Deloitte, Ernst&Young.

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

Пример. Перед запуском системы для оплаты проезда «Тройка» в Московском метро консультанты просчитали экономику, затраты, ресурсы, схему работы.

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

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

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

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

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

Это команда, которая создаёт инструменты для сбора данных и далее для управления компанией на основе данных. Например, инструмент для сбора данных Share point для сотрудников или автоматический сбор данных.

BI — решение на собственном движке или внутри сервисов Tableau, Power BI, QlikView. Позволяет создавать автоматические отчёты, которые демонстрируют эффективность работы компании.

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

В таких случаях это смежная с менеджментом специальность.

Пример. В Яндексе операционная команда запускает бизнес в новых городах и странах.

Дополнительный анализ:  Анализ воронки продаж: цели, выгоды и пример

Функция, близкая к отчётности и стратегии. Такие команды создают системы KPI, поддерживают OKR (инструменты планирования), премии, расчёт показателей эффективности, бонусы — количественные показатели, которые крупные компании используют для сохранения конкурентоспособности и развития.

Business Intelligence (BI) — бизнес-аналитика, точнее — анализ бизнес-данных для принятия управленческих решений

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

Итак, как говориться, пора разобраться, ради чего все это затевалось. Все это, в смысле «бизнес». И если сами руководители и/или работники этого не знают, «

тогда мы идем к вам

» (ц). На самом деле, это очень важный этап и тут есть свои, совсем неочевидные сложности.

Традиционно, начнем с определений. Что есть бизнес? Бизнес, говоря по-русски, это просто некая деятельность или занятие, на которые мы тратим свои ресурсы (время, деньги) и свои способности. И любой «бизнес» существует не сам по себе в вакууме, он служит «удовлетворению потребностей».

И чтобы нам было все это славословие более понятным, давайте отвлечемся от гранита науки, к более податливым материям – к примерам. Представим, что перед нами стоит задача исследовать бизнес «Почты России». Этот пример, думаю, будет многим близок, поскольку с почтой каждый из нас сталкивался.

Итак, что же является целью данной организации? Какую потребность она (организация) удовлетворяет? Многие сходу ответят что это – «доставка почтовых отправлений». И это будет не совсем верным ответом. Спросим несколько иначе, а что отражает потребность заказчиков в «отправке писем, посылок и так далее»?

Чувствую, что будут недовольные ухмылки, мол «крутишь, вертишь, надурить хочешь» автор. Ан нет. Еще раз взглянем внимательно. Человек не родился со знанием, что для того, чтобы чего-то сообщить другому человеку за лесами и полями (в смысле который находится очень далеко) надо сначала все это записать на бумагу, запаковать в конверт и отправить с помощью почты. Таковыми были требования вследствии неразвитости средств связи.

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

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

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

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

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

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

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

Очевидно, что бизнес-аналитик должен понять и зафиксировать все требования и задачи, которые будут озвучены, именно с точки зрения бизнеса – удовлетворение вполне конкретных потребностей. При этом, при их описании, желательно избегать всевозможных туманных определений задач в стиле «сделать счастливой тетю Глашу», или же постараться максимально их конкретизировать (например, «для должности «помощник»– уменьшить объем выполняемых работ до 5ти операций, общим временем не более 6 часов в день»).

Ну и самое главное, все задаваемые требования должны иметь численное, абсолютное значение. Допустим, мы получили требование: «уменьшить затраты на доставку отправлений в рамках одной области на 5%». Уменьшить что? Затраты чего: труда сотрудников, времени доставки, стоимости доставки или все вместе в некой пропорции? Как все это считать? В идеале, хотелось бы, чтобы требования фиксировались в виде, близком к следующим примерам:

Затраты времени на доставку отправлений массой до 1 кг, в пределах 300 км от места отправления, с момента оформления отправления в офисе, до момента готовности к его выдаче в отделении получателю, необходимо уменьшишь с 24 до 16 рабочих часов.Себестоимость доставки отправлений в пределах 300 км от места отправления, массой до 1 кг, с учетом:

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

Должна быть снижена с 50 до 45 руб., в пересчете на одно отправление, при общем количестве отправлений не менее 50 в день.

Наверняка тут же возразят, «

a как быть с требованиями в стиле «увеличить прозрачность процессов?

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

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

или же

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

Дополнительный анализ:  АВТОНОМНАЯ НЕКОММЕРЧЕСКАЯ ОРГАНИЗАЦИЯ ДОПОЛНИТЕЛЬНОГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ УЧЕБНЫЙ ЦЕНТР ПО ОХРАНЕ ТРУДА "АНАЛИТИКА ТРУД" - Тверь - ОГРН 1096900000020


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

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

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

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

Случай из практики

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

Как мы видим, требование в принципе простое. При поверхностном анализе – все прекрасно:

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

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

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

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

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

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

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

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

  • Товары вводились одновременно несколькими операторами по новым поступлениям из накладных, в результате каждая приходная накладная использует свой вариант товарной позиции;
  • Новые товарные позиции вводятся одним ответственным лицом, но таким образом «эмулируется» отсутствующий или отключенный «партионный учет» в учетной системе;
  • «Двойники» являются результатом объединения нескольких баз и многие из них (позиций-двойников) отсутствуют в остатках и применяются только для корректного отображение исторических документов/проводок, не влияя на текущую работу.

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

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

И единственное, как бизнес-процессы любого предприятия могут повлиять на прибыль – только снижением издержек включая затраты времени. Ценообразование, формирование требований к продукции, объемы производства/реализации – все это касается маркетинга и только маркетинга.

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

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

→ Продолжение тут

Источники изображений:

1. Изображение маяка взято тут.2. Песик отсюда

Оцените статью
Аналитик-эксперт
Добавить комментарий

Adblock
detector