Материалы

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

Четкий план действий – ключ к успеху

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

Бизнес – требования в первую очередь

Управление эффективностью работы предприятия – это стратегическая бизнес – инициатива. Это – не просто офисная операционная система. Бизнес – требования должны являться ядром решения этой задачи. Какая технология лучше – это уже второстепенный вопрос. Прежде чем переходить к сравнению OLAP, ROLAP, гибридных  и OLAP – подобных технологий, необходимо определить, например, сможет ли часть этого ПО поддерживать комплексное распределение финансов для процессов годового бюджета. Многие компании пропускают этот этап, считая, что они «узнают» хорошую систему как только её увидят. Это – большое заблуждение. Постарайтесь его избежать. Опросите руководство, получите их детальные требования, а затем проведите их категоризацию и определите приоритеты. Возможно, вы захотите уточнить, что им нравилось и не нравилось в других системах, используемых для решения  бизнес – задач. На этом этапе вам стоит найти человека, который имеет опыт в сфере управления качеством бизнеса и показать ему полученные требования. Реально недостижимые запросы в вашем списке могут привести к тому, что вы отфильтруете действительно полезного для вас разработчика. Ваш список требований к ПО должен быть сфокусирован на решении текущих проблем, не игнорируя потенциальные преимущества от управления качеством в будущем, зачастую не включаемых из-за недостатка времени на обдумывание или  находящихся вне вашей профессионально компетенции. После категоризации и определения приоритетов бизнес - требований, можно переходить к следующему этапу: выбору разработчика.

Запрашивать предложения или нет?

Запрос предложений – это долгий и трудоемкий процесс, практически не приносящий положительных результатов. Почему его регулярно используют? Это происходит потому, что человеку, ищущему  разработчиков необходимо выбрать лишь несколько лучших кандидатов. Существуют и другие пути (см. следующий раздел), но если вы не будете задавать детализированных вопросов – это станет самой крупной ошибкой на данном этапе. К примеру, если вы спросите разработчиков «будет ли ваша система работать с Excel», то вы не услышите ничего, кроме «да». Поможет ли вам эта информация дифференцировать разработчиков? Конечно, нет. Но если вы будете задавать все более детализированные вопросы (Есть ли дополнительные модули? Можно ли задавать команды в Excel и получать доступ к базе данных? Является ли интерфейс файлом внешней загрузки? Поддерживает ли интерфейс доступ и к чтению, и к изменению?), то получите достаточно информации для отсеивания разработчиков. Запросы следует составлять с учетом требований к управлению качеством.

Выбор разработчика

Кто будет отправлять запросы? Или, если вы пропускаете этот этап, кто будет составлять короткий список разработчиков? Часто, компании составляют список, отталкиваясь от размеров бизнеса разработчиков: чем он крупнее, тем больше вероятность, что о нем слышали. При таком подходе вы рискуете переплатить за то, чем не будете пользоваться. Постарайтесь не стать одним из них. Еще одна опасность такого подхода заключается в том, что вы можете пропустить малоизвестного разработчика, чье решение, тем не менее, отвечает всем вашим требованиям. Еще одним важным элементом поиска является его способы. Быстрый поиск в Google или иной поисковой системе, принесет множество общедоступных материалов, отчетов и руководств пользователей. Свободный поиск материалов не так хорош по нескольким причинам: зачастую, это – завуалированные маркетинговые материалы или обобщенные обзоры, отсылающие вас к дополнительным материалам. Если вы намерены приобрести решение для управления эффективностью бизнеса стоимостью в сотни тысяч долларов, то  почему бы не выделить небольшое количество средств, чтобы получить уверенность в правильности выбора. Важно узнать мнение опытного специалиста в области анализа или управления качеством бизнеса.

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

Оценка разработчиков

Когда вы будете просматривать отрепетированные и заранее приготовленные видео демонстрации продуктов, вы, вероятно, потратите много времени на изучение массы сценарных демонстраций или обоснований концепций. Сейчас  существует множество систем для управления качеством бизнеса, имеющих  схожий интерфейс и набор функций. Вы не сможете дифференцировать эти системы без рассмотрения того, как именно вы будете с ними работать. Используя собственные ресурсы или привлекая экспертов, вам нужно определить наиболее важные аспекты и/или проблемные аспекты, ради которых и осуществляется поиск решения. Далее, вам нужно разработать собственный сценарий демонстрации, в которой разработчик покажет, насколько его продукт подходит для решения ваших конкретных задач. Например, если вы распределяете текущие расходы по отдельным бизнес – подразделениям в зависимости от их процентного соотношения в консолидированных расходах, то разработчика следует спросить, как его решение может поддерживать этот сложный, многоступенчатый процесс. После этого можно легко оценить разработчиков по критерию: выполнена поставленная задача или нет. Конечно, в большинстве случаев, при демонстрации все будет выглядеть легко и понятно. Это дает вам право на вопрос: «а каким образом были получены результаты»? на этом этапе будут выявлены основные различия. Некоторые продукты используют комплексные логические  правила, создаваемые специалистами для конкретных задач. Другие используют «теневые счета» или логические объекты для поддержки единовременных калькуляций. Лучшие из этих решений содержат встроенный функционал для осуществления этих процессов и упрощения их использования и контроля. Если вы рассмотрите свои основные требования в этом ключе, то некоторые участники списка будут вынуждены его покинуть.

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

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

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

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

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

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

Подробнее
Обзор PROPHIX
Краткий обзор возможностей PROPHIX
Истории успеха
Узнайте, как другие компании используют PROPHIX для повышения эффективности своей деятельности

продвижение сайта