Функциональные спецификации проекта
После формирования Группы внедрения, мы начали встречаться с продавцом системы на собраниях по 21/2дняприблизительно раз в три недели, чтобы зафиксировать на бумаге конкретные подробности требований к системе, которые мы указали в наших Предложениях о сотрудничестве.
Этот предварительный план стал рабочим документом, на основе которого продавец будет проектировать или модифицировать ПО. Он также стал нашей мерой измерения фактически работающего ПО. При создании этого документа мы стремились к содействию не только со стороны складских пользователей, но также со стороны функциональных отделов, которые косвенно получали выгоды от системы. Это помогло предложениям о сотрудничестве "обрасти мясом", необходимой конкретизацией.
Система была разделена на сегменты, такие как приемка, отбор на производстве, отбор заказов клиентов, размещение готовой продукции и т.д. Каждый сегмент завершался по одному за раз. Мы не пытались подробно спроектировать систему в целом или работать на множестве участков системы одновременно.
После каждой встречи лицом к лицу с нашим продавцом, документ о функциональных спецификациях проекта обновлялся и возвращался в нашу внутреннюю группу для рассмотрения и одобрения. Этот процесс позволял дорабатывать документацию, пока каждый еще помнил все подробности. Когда все части были завершены таким образом и объединены вместе, мы получили законченный документ, на основе которого продавец мог начать проектирование и модификации конкретного ПО.
|
|
|
На этой стадии осуществления проекта, мы узнали (опытным путем, конечно), что есть два основных риска, которых нужно избегать, чтобы минимизировать возможные проблемы при разработке ПО:
1. Составляем как можно больше блок-схем процедур.
Мы обнаружили, что эти процедуры, задокументированные в виде блок-схемы, а не в виде текста, имели меньше шансов на непонимание программистом продавца ПО. Во многих случаях, фактическими программистами ПО были не те люди, которые помогали проектировать систему и знали требования.
Программисты не могли "читать между строк" в записанной процедуре, как это могли делать некоторые члены Группы внедрения. В результате, могло быть два различных толкования одной и той же процедуры. Не думайте, что менеджер проекта продавца будет смотреть через плечо программиста и объяснять каждую часть документа.
Если продавец этого сделать не может, то нужно подумать о выделении внутренних ресурсов (из Группы внедрения), чтобы "нянчиться" с продавцом во время этой стадии программирования проекта.
2. Второй большой риск, который может быть опаснее первого, в том, чтобы «перепроектировать» систему. Очень легко для Группы внедрения в своем энтузиазме при проектировании системы потерять чувство реальности.
|
|
|
Мы хотели, чтобы система могла справиться с любой возможной ситуацией, которая могла произойти на нашем складе при перемещении продукции и материалов. В некоторых случаях, мы тратили очень много времени на поиск решений в складских функциях, на которые, вероятно, приходился 1% наших общих складских торговых операций.
Эти вопросы часто относились к подгоняемому под потребителя ПО, так что значительная часть работы по программированию тратилась на относительно небольшую часть нашего складского бизнеса. К сожалению, наш продавец неохотно говорил "Нет!" в ответ на некоторые наши просьбы, даже несмотря на то (что в то время было нам неизвестно), что мы значительно усложняли требования к программе.
Если бы мы лучше понимали те сложности в ПО, которые мы создавали для нашего продавца, мы бы отменили или уменьшили эту часть системы. Продавец не хотел показаться неспособным к сотрудничеству в ответ на наши просьбы, но это бы позволило обеим сторонам уменьшить затраты и меньше распылять наши силы.
|
|
|
Из-за сложности этих систем, я сейчас твердо верю в необходимость первоначальной функциональности системы насколько можно простой, чтобы система была установлена за более короткий срок. Это позволит получить выгоды и добиться успеха быстрее (и, вероятно, с меньшими усилиями) и добавлять модификации и дополнения в любые более поздние сроки.
Разработка ПО продавцом
Первое, о чем каждый думает на этой стадии проекта, что есть возможность передохнуть. После интенсивных усилий по созданию Функциональных спецификаций проекта, работа над проектом переходит почти полностью к продавцу.
Это, вероятно, наиболее опасная часть проекта, где вы, как заказчик, имеете наименьшее влияние на процесс. В теории, именно здесь продавец (используя Функциональные спецификации проекта) модифицирует и подгоняет под ваши требования применение ПО.
Не поддавайтесь искушению снизить свое внимание к проекту. Настаивайте на частых, регулярных встречах для обсуждения прогресса в разработке ПО. Мы узнали, что это очень важно, особенно когда отправились в офис продавца, чтобы обсудить выполнение работы.
Мы узнали, что в ожидании периодических встреч, например, раз в месяц, мы предоставляли больше времени, чем нужно для исследования любой проблемы с ПО. Продавец, по вполне понятным причинам, вовсе не стремился раскрывать проблемы при разработке ПО. Чем больше у продавца времени, тем больше возможностей, чтобы выбраться из «пике». Однако если он подлетал слишком близко «к земле», то «крушение самолета» становилось неизбежным.
|
|
|
"Крушение" для нас означало, что не было никакой возможности для нашего продавца закончить ПО по согласованному в договоре графику, потому что два важнейших месяца работы над ПО не привели к созданию ожидаемого продукта. В этот момент, мы действительно начали "нянчиться" с продавцом, отправляясь к нему лично раз в две недели. Члены группы отправлялись туда по очереди (два управляющих складом и я) и достигли значительно лучших результатов.
Мы поняли на этой стадии осуществления проекта, что, кажется, была прямая связь между количеством и объемом ресурсов, которые наш продавец посвящал проекту и частотой, с которой мы встречались. Мы обнаружили, проявив настойчивость, что наш продавец серьезно недооценил трудности и требования к ресурсам при адаптации своей старой системы для открытой UNIX системы в соответствии с временными рамками нашего договора.
То, что осталось от первоначального плана действий
Наш продавец порекомендовал и мы, наконец, согласились (т.к. другого приемлемого варианта не было), разделить систему на Стадию 1 и Стадию 2 проекта. Стадией 1 станет базовая система отслеживания, использующая радиотерминалы, но управляемая операторами.
Оператор вилочного погрузчика инициирует тип складской деятельности, который нужно выполнить, или при размещении продукции или в функции отбора. Оператор вводит через клавиатуру или сканирует номер единицы хранения, и затем система управления складом направляет оператора на ближайшее подходящее место для выполнения этой задачи.
Стадия 1 позволила нам достичь почти совершенной точности в местоположении и количестве нашей продукции. Это позволило решить нашу самую большую проблему при хранении готовой продукции навалом — где конкретно находится продукция?
На Стадии 2 к радиотерминалам и отслеживанию добавится логика управления системой, которая позволит лучше использовать наш складской труд, позволяя системе управления складом чередовать все складские задачи среди всех складских операторов. В конечном счете, это позволит интегрировать заказы клиентов с системой управления складом и оптимизировать функции отбора заказов и отгрузки.
Вместо того чтобы у каждого оператора была партия напечатанных заказов и определения вручную последовательности отбора продукция, система управления складом получит возможность отбирать волнами или партиями, и над множеством заказов можно будет работать одновременно одному или группе операторов. Стадия 2 предоставит максимальную гибкость в использовании трудовых ресурсов и выполнении задач по всему складу.
Некоторые итоги
С нашим новым активным участием в разработке продавцом ПО, мы смогли перейти к завершению во второй половине 1993. Между февралем и ноябрем 1994 четыре системы отслеживания на наших складских объектах начали работать и обеспечили немедленные результаты в повышении точности наших товарных запасов.
Разница в точности между старой и новой системами была ошеломляющей. Вскоре стало очевидно, что мы невероятно недооценивали объем времени, который водители вилочных погрузчиков тратили на поиски готовой продукции каждый день.
Мы начали работать над обоснованием применения нашей системы отслеживания и управления складом в оптовой базе «Lawn & Garden» на нашем объекте в Годдарте, Канзас летом 1994. В это время мы отслеживали время, которое операторы тратят на поиск продукции. Мы обнаружили, что до двух часов в смену (12-часовые смены) ухолили только на поиски продукции.
Возможно, эта недооценка времени поиска продукции была подсознательной. Ни один управляющий складом не захочет признать, что операции на складе настолько дезорганизованы и столько времени ежедневно тратится только на поиски нужной продукции. В нашем первоначальном обосновании системы, мы мало говорили о времени на поиск продукции и делали акцент на повышении производительности труда. Очевидно, что когда не нужно искать продукцию, производительность действительно повышается, но мы ожидали совсем другого.
Выгоды от использования системы отслеживания с помощью радиотерминалов с самого начала были очень значительными. Наш первый склад готовой продукции с установленной системой имел 96% точность при циклическом подсчете после первой недели работы (мы, в сущности, провели реинвентаризацию каждого склада, когда система начинала работать для каждого места хранения на складе). Сверхурочные часы за первые три месяца (март - май во время нашего квартала наибольшей нагрузки) при использовании системы снизились на 60% по сравнению с тем же периодом прошлого года. К концу 1994, восемь должностей контролеров товарных запасов были упразднены (люди перешли на другую работу, никто не был уволен).
Любой человек на складе подтвердит положительные последствия от внедрения новой системы, но лучше посмотреть на таблицу с результатами. Сравнение января - июня (наши максимальные нагрузки) 1995 с январем - июнем 1994 на объектах в Винфилде и Годдарте показало следующие цифры:
| Складская категория | % изменений 1995 по сравнению с 1994 |
| Отгружено и продано товаров, в долларах | 7,1% |
| Общая зарплата работников обслуживания | -12,1% |
| Общее количество обработанных трейлеров (погрузка или разгрузка) | 8,4% |
| Внешние складские затраты | -40,0% |
| Затраты на перевозку грузов | -44,0% |
| В среднем, на товарные запасы «первый на входе, первый на выходе» за месяц | -16,0% |
| Обработка информации о товарных запасах | -13,4% |
Эффект домино от точных в реальном времени товарных запасов (99,2%) и оптимизации труда благодаря ПО оказался бесспорным. Возросли объем наших продаж и объем продукции, а наши трудовые затраты снизились. Если вы сравните первую половину 1995 с первой половиной 1993, когда мы еще полностью полагались на «бумажную» систему, то увидите, что объем отгруженных и проданных товаров в долларах и количество обработанных трейлеров возросли на 15,2% и 15,1% соответственно, а общие затраты на зарплату обслуживающего персонала уменьшились на 11,7%.
Заключение
Может быть, мы проиграли некоторые сражения на пути к внедрению нашей системы управления складом, но мы, видимо, выиграли войну. Когда пишутся эти строки, обе стороны активно обсуждают завершение Стадии 2, что позволит нам сделать еще один шаг вперед в повышении производительности и совершенствовании складского хранения.
Мы увидели, что нельзя добиться чего-то большого, если не рисковать и не затрачивать усилий. Важно, чтобы любая компания, стремящаяся улучшить свои операции складского хранения с помощью подобных систем, знала не только что она хочет, но также как этого добиться. Надеюсь, что этот учебный пример поможет в работе над проектами по внедрению систем.
Дата добавления: 2019-03-09; просмотров: 370; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!