Настольная Книга Управляющего Складом - Джеймс Томпкинс. 1. Проблемы и задачи складского хранения. Складское хранение и товародвижение
 Скачать 14.49 Mb.
|
|
Подробные предложения о сотрудничестве и критерии ранжирования продавцов Подробные предложения о сотрудничестве и критерии ранжирования продавцов стали нашим "ангелом-хранителем", благодаря которому мы могли передвигаться в лабиринте из продавцов-кандидатов. Эти документы помогали выявлять слабости в функциональных возможностях ПО продавцов, их соответствующий опыт, подходящие рекомендации, завершенные установки и стоимость системы. Наши предложения о сотрудничестве составили 36 стр. и учитывали наши конкретные требования для всех складских функций, включая оптимизацию труда и время отклика радиотерминалов. Как оказалось, документ с нашими предложениями о сотрудничестве был длиннее некоторых предложений, что мы получали от предполагаемых продавцов. Для членов нашей группы это было красноречивее всяких слов. Мы также все больше убеждались, что приняли мудрое решение использовать очень конкретные, взвешенные критерии ранжирования для оценки продавцов. Цель была не только в том, чтобы, насколько возможно, избавиться от субъективности в процессе ранжирования, но и в том, чтобы позволить продавцам соревноваться друг с другом в честной борьбе. Готовых систем нет Наш опыт при оценке продавцов убедил нас, что подходящих нам готовых систем управления складом нет. В результате, то, что мы собирались купить, это опыт продавца в применении ПО, установке системы и завершения установки вовремя и в соответствии с бюджетом. Мало продавцов предложили нам фиксированные или предельно допустимые цены за свои системы. Нежелание сделать это показывало нам, что, вероятно, этот продавец на самом деле не знал, каких затрат потребует разработка нашей системы. Оптимизация труда стала принципиальным фактором обоснования нашей системы и требований к функциональным возможностям ПО. Мы считали опасным заключение неокончательного соглашения с продавцом, когда стоимость ПО определяется после подписания договора. В этом случае, пришлось бы полагаться на милость продавца в подгоне ПО под потребителя в том, что касается времени и материалов для завершения работы. Без подробных предложений о сотрудничестве этот вариант развития событий наиболее вероятен. Продавец менее охотно соглашается на фиксированные цены, если получает смутные требования или имеет дело с потенциальным клиентом, который сам не знает, чего хочет от своей системы. Разработка подробных требований в начале работы над проектом стоит не так дорого, если сравнить с альтернативой, когда приходится надеяться, что все образуется само собой при внедрении системы. Слишком много компаний, с которым я общался во время изучения продавцов, потратили на свои системы управления складом больше средств, чем первоначально планировалось или выделялось в бюджете. Заставьте продавца иметь дело с вашими требованиями Наша группа начала понимать, что продавцы систем, кажется, делятся на две большие категории: тех, кто изучает ваши требования, и тех, кто стремится продать свои базовые системы. Эта вторая группа побуждает вас изменить свои складские операции в соответствии с возможностями их систем. Хотя это, может быть, чрезмерное упрощение, но в значительной степени здесь видны стремления и гибкость некоторых продавцов. Мы хотели, чтобы продавцы рассказывали нам о том, как их системы будут соответствовать нашим уникальным требованиям. Благодаря разработке подробных требований, мы не позволяли продавцам «заливаться соловьем» о возможностях их систем в общем и целом. При проверке множества рекомендательных писем я постоянно удивлялся тому, как много компаний покупали системы управления складом только потому, что они предлагались на рынке и привлекательно выглядели. Они покупали, веря, что продавец может предоставить им нужную систему без реальной демонстрации ее возможностей по удовлетворению их специфичных требований. Мы посетили одну установку системы на складе с продавцом на восточном побережье в 2:00 только для того, чтобы обнаружить, что работала там частичная система (только отбор) и никакого сходства с нашим складским хранением навалом. Сказать, что этот продавец потерял доверие членов нашей группы, это, значит, ничего не сказать. Мы пролетели через полстраны (только во время учебы в колледже или при рождении моего сына я так долго не спал ночью), а этот продавец даже не читал наши требования, не понимал их и/или наши потребности его не интересовали совсем. Если продавец не может продемонстрировать функциональные возможности существующего ПО, то должен ясно продемонстрировать, как он будет соответствовать вашим специфичным требованиям. Другой продавец встречался с нами три раза тремя различными группами людей. На третьей и последней встрече, никто из представителей продавца даже не читал наши предложения о сотрудничестве перед приездом на наш объект. Три раза при общении с этим продавцом приходилось все начинать сначала. Этот продавец также хотел продать нам свою систему, и его не интересовали наши требования. Мы отказались от нескольких презентаций, потому что НАШИ требования там не учитывались. Широко известно высказывание, что нельзя верить тому, что говорит продавец. Однако именно этого ожидали от нас некоторые компании, с которыми мы вели переговоры. Критерии ранжирования продавцов Критерии ранжирования продавцов шли рука об руку с нашими предложениями о сотрудничестве. Ключевой момент здесь был в определении (до каких-либо контактов с продавцами) относительной ценности каждого критерия. Какие приоритеты у системы? Важнее ли функциональность ПО, чем платформа аппаратных средств? В самом простом виде выбор продавца – это оценка рисков. Мы, может быть, были достаточно наивными вначале, полагая, что сможем найти продавца, полностью удовлетворяющего всем нашим требованиям. Мы посетили множество складов с различными продавцами, и среди них не было совершенно одинаковых. Несмотря на тот факт, что основные функции складского хранения (приемка, размещение и хранение, отбор и отгрузка) являются универсальными, но каждая установка оказывалась в своем роде уникальной. Определение ключевых критериев оценки и их соответствующая значимость, позволили нам пойти на риск в тех областях, которые мы не считали важнейшими для успеха системы. Функциональность ПО была определена нашей группой как наш самый важный, получивший наибольшую значимость фактор. Этот критерий стал лакмусовой бумажкой при изучении наших продавцов-кандидатов. Изменение правил игры Яркий пример необходимости придерживаться значимых критериев оценки обнаружился внутри нашей проектной группы. Несмотря на вышеуказанные рекомендации, мы были втянуты в дискуссию об аппаратных средствах по сравнению с ПО с нашим отделом информационных систем, которая продолжалась полтора года. Это привело к тому, что осуществление нашего проекта было отложено на этот срок, и, что более важно, эта временная задержка привела к потерям производительности, которые восполнить нельзя. Мы затратили множество усилий, чтобы выйти из этого тупика. Это обошлось нам в несколько сотен тысяч долларов потерянной экономии из-за того, что система не была установлена раньше. Эта задержка и окончательное соглашение (о платформе аппаратных средств) позднее обошлись еще дороже. Рекомендательные письма продавцов Чем больше мы общались с продавцами, тем меньше верили их рекомендательным письмам. Мы не ожидали увидеть плохие рекомендательные письма, это было бы странно. Однако мы хотели составить представление о продавце на основе слов его клиентов, а не самого продавца. Разница между тем, что говорили их клиенты по сравнению с утверждениями продавцов "система может все", помогли нам увидеть, насколько хорошо продавцы выполняли то, что обещали. Когда несколько продавцов, которых мы оценивали, не смогли предоставить нам уровень функционального описания, который был нам нужен, мы стали проводить еще больше времени с клиентами, давшими им рекомендации, чтобы увидеть, какая функциональность была стандартной в их ПО, и какие функциональные возможности нужно было подгонять под потребителя. Единственный самый повторяемый совет или комментарий был в том, чтобы не рисковать со значительно подогнанным под потребителя ПО. Не будьте "подопытными кроликами" при разработке ПО – такое пожелание было повсеместным. Выбор продавца Хотя мы были намерены не превращаться в "подопытных кроликов" при разработке функционального ПО, нашей проектной группе не так повезло с платформой аппаратных средств. Наш проект был "заморожен" в течение 18 месяцев, потому что выбранный нами продавец не работал с нужной платформой аппаратных средств (IBM). В результате, мы не могли получить одобрение руководства корпорации на осуществление проекта (капитальные расходы были достаточно большими, чтобы потребовалось одобрение руководства). Мы продолжали искать других продавцов с "нужной" платформой аппаратных средств, но, наконец, пришли к выводу, что остальные не могли продемонстрировать необходимую функциональность ПО. Наконец, выбранный нами первоначально продавец, предложил адаптировать свою систему для открытой (UNIX) системы на IBM RS/6000. Это означало компромисс со стороны нашего продавца, и руководство, наконец-то, одобрило осуществление нашего проекта. Подписание договора с продавцом Эйфория после получения одобрения руководства корпорации длилась недолго; ведь нам еще нужно было подписать договор с нашим продавцом, чтобы реальная работа над нашей системой могла начаться. После того, как мы так внимательно работали над критериями ранжирования продавцом, мы не могли легкомысленно или в спешке подписать договор только для того, чтобы могло начаться проектирование нашей системы. Мы не только добились того, чтобы фиксированные цены или предельно допустимые цены за систему были включены в договор, мы также позаботились о том, как и когда будут выплачиваться деньги. Последним средством воздействия на нашего продавца у нас стало одобрение платежа за завершение работы. Мы настояли, и наш продавец согласился, что мы не будем платить, пока:
Мы полагали, что эти меры финансово обезопасят нас в некоторых частях проекта, таких как освоение аппаратных средств, где были более высокие риски, чем в других частях проекта. Эта статья договора позднее доказала свою полезность, когда на одном из этапов разработки ПО, мы удержали платеж за следующий промежуточный этап, потому что он не был выполнен к нашему удовлетворению. Мы не стремились создать финансовые трудности для нашего продавца, но мы платили за результаты, а не за усилия. Возможность удержать платеж, более чем что-либо еще из того, что мы пытались делать во время нашего проекта, было способно направить внимание нашего продавца на конкретные проблемы, вызывающие задержку или замедление прогресса. Мы увидели, что проекты интеграции систем, такие как наш проект системы управления складом, в сущности своей – это ничто иное как конкуренция за ресурсы продавца. Происходит ли задержка на проекте вашей компании или у кого-нибудь другого, будет эффект домина на все проекты продавца в распределении его ресурсов. Продавец, как правило, делает оценку на основе человеко-часов необходимых на проект. Кроме случаев, когда продавец придерживается правила не браться за следующий проект, пока не выполнена определенная часть существующих проектов, с его стороны всегда есть вероятность непродуманных действий. Как и большинство системных интеграторов, наш продавец был небольшой компанией с меньше чем 100 работниками. Поток наличных – вот то, что помогает этим компаниям выжить. Больше денег, как правило, платят продавцу в первой половине проекта. Поэтому эти небольшие компании продолжают отдавать приоритет получению новых проектов и заказчиков. Новые заказчики, и увеличение денежных потоков, означают также увеличение нагрузки на их человеческие ресурсы. Нетрудно понять, как несколько небольших задержек могут все вместе привести к значительным проблемам с распределением этих ресурсов. В этот момент тот, кто "громче крикнет" получит внимание продавца. Мы обнаружили, что наш договор с возможностью удержать платеж за незавершенную работу позволял нам "кричать" достаточно громко. Мы также оговорили возможность покупки аппаратных средств напрямую, а не через системного интегратора (нашего продавца), но со «сдачей под ключ», с одним ответственным за завершение работ. Благодаря долгосрочному корпоративному соглашению «Rubbermaid» с компанией IBM, чего не было у нашего продавца, компания «Rubbermaid» смогла закупить аппаратные средства RS/6000 дешевле. Мы договорились о плате за интеграцию (процент от стоимости аппаратных средств) с нашим продавцом, что обеспечивало его ответственность за интеграцию аппаратных средств (включая радиотерминалы) с его ПО. Даже несмотря на плату за интеграцию, мы сэкономили деньги по сравнению с закупкой аппаратных средств через нашего системного интегратора. В общем, мы стремились обезопасить себя в трех основных сферах:
Чем проще здесь, тем лучше. В проекте достаточно других сложностей. Не оставляйте себя с неокончательным договором и надеждами, что справитесь с ситуацией лучше, чем другие. Как моя жена и я часто говорим двум нашим детям: "ЧП не планируются". Формирование группы внедрения С самого начало работы группы управления, мы стремились привлечь к участию в проектировании отдельных частей системы почасовых складских рабочих, что было необходимо для успеха проекта. Группа внедрения была межфункциональной и состояла из представителей следующих отделов: Инженерные коммуникации (менеджер проекта), Отдел информационных систем, Производственное планирование, Распределение (управляющие и почасовые работники), Полуфабрикатов (управляющие и почасовые работники), Финансов. Общее количество членов Группы внедрения составило 14 человек, и этот проект был признан приоритетным в том, что касается распоряжения временем членов этой группы. Насколько возможно, мы стремились забывать о наших должностях, когда проводили собрания группы или встречи с продавцом. Получение информации напрямую от почасовых работников помогло выявить действительные, а не предполагаемые проблемы складского хранения. Мы исходили из того, что проект системы должен осуществляться через консенсус группы. Это означало, что каждый мог лично не соглашаться с решением, но поддерживать решение группы. (ПРИМЕЧАНИЕ: До формирования группы внедрения, все члены группы прошли обучение «Rubbermaid» по постоянному совершенствованию, где делался акцент на создании групп, работе в группе и умениях приходить к консенсусу.) Синергетический эффект от работы Группы внедрения привел к появлению гораздо более разностороннего проекта системы, чем могли бы создать члены группы по отдельности. Другим важнейшим элементом работы группы была вовлеченность всех членов группы в этот проект. Этот проект системы управления складом был, возможно, наиболее сложным для любого из нас. Члены группы помогали при внедрении системы на двух объектах в Винфилде, особенно на самом складе, где система с радиотерминалами, работающими в реальном времени, стала радикальным переходом от бумажной системы. Никогда не недооценивайте требования к ресурсам Как менеджер проекта, я выучил один из самых важных уроков при проектировании и внедрении этой системы: НИКОГДА НЕ НЕДООЦЕНИВАЙТЕ ТРЕБОВАНИЯ К РЕСУРСАМ. Во время календарного 1993 года, когда происходило проектирование нашей системы, разработка ПО, установка радиотерминалов, первоначальное обучение пользователей и проверка системы, наша Группа внедрения потратила свыше 11000 человеко-часов на этот проект. Это эквивалентно почти шести человеко-годам, или шести людям, работающим полный рабочий день в течение года и занимающихся только проектом системы управления складом. Если вы сами не занимались подобным проектом, то исключительно трудно оценить, сколько времени потребуется для осуществления такого проекта. Одним из наших руководящих принципов было то, что компания «Rubbermaid» никогда не должна быть «узким местом» или задерживать проект. Мы хотели оказывать давление на системного интегратора, требуя соблюдения всех дат промежуточных этапов, чтобы ему не приходилось ждать нас (заказчика) при выполнении задачи. Нужно ли говорить, что чтобы получать необходимые внутренние ресурсы для такого проекта, высшее руководство должно обеспечивать поддержку и предоставление этих ресурсов. Без такой поддержки, заказчик становится «узким местом», и драгоценные ресурсы продавца (люди) отправляются на другой проект. Системный интегратор не может себе финансово позволить бездельничать в ожидании заказчика. Похожей аналогией будет наш производственный объект, который мы используем для обучения работающих на производстве людей. Когда наш станок для литья пластмасс под давлением или пескодувная формовочная машина не изготавливают качественные детали из-за простоя или брака, то машинное время и труд оператора потеряны навсегда. Возможности для полного использования не только ресурсов продавца, но поддержания работы над проектом внутри компании ограничены. Чем больше проект откладывается, тем труднее собрать необходимые людские ресурсы от обеих сторон проекта. |