Неспособность определить свои нужды



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

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

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

Функции или проектирование

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

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

Когда забывают, кто здесь главный

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

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

Нереальное расписание

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

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


Дата добавления: 2019-03-09; просмотров: 162; Мы поможем в написании вашей работы!

Поделиться с друзьями:






Мы поможем в написании ваших работ!