Работа с местни интегратори по проекти за Smart Locker: ясен модел на сътрудничество

В YS LOCKER виждаме, че хардуерните разговори се движат по-бързо, когато въпросът за работа вече е ясен. Какво трябва да определи купувачът от чужбина, когато местен интегратор ще свърже, инсталира или управлява проект за интелигентно-шкафче? Целта не е да се даде универсално обещание за един шкаф, софтуерен пакет или метод на инсталиране. Целта е да се даде на задграничните B2B купувачи дисциплиниран начин да дефинират проекта, преди да сравнят офертите.

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

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

Много оператори-на шкафчета за колети вече използват собствен оперативен софтуер или платформа на трета-страна. В тези проекти YS LOCKER може да предостави API за контролна платка за заключване- или протокол за интегриране на проекта. Терминален софтуер, брандиране, работни процеси за доставка и вземане, сървърни интерфейси и функции за управление също могат да бъдат обсъдени в съответствие с потвърдения обхват на проекта. Ние не представяме функции на трети-страни или персонализиран софтуерен обхват като функция по подразбиране на всяко шкафче.

Започнете с въпроса, който е най-близо до реалния риск на купувача. За тази тема, това са роли на доставчик и интегратор, доставка на кабинет, работа на локален сайт, собственост на софтуера, обмен на протоколи, тестване, ескалация и контрол на промените. Изградете кратка таблица, която изброява текущото състояние, собственика, който може да го потвърди, наличните доказателства и решението, което все още е необходимо. Това създава по-ясна заявка за оферта и по-полезен технически преглед.

Масата не трябва да спира до шкафа. Той трябва да обхваща физическото оформление, последователността на доставка и събиране, крайните устройства, където е необходимо, условията на мрежата и захранването, операционния софтуер и ролята на екипа на обекта след въвеждане в експлоатация. Когато дадена функция принадлежи към платформата на клиента или платформа на трета-страна, я идентифицирайте ясно. Когато това е заявка за-специфично персонализиране на проект, идентифицирайте я като заявка, а не като стандартна претенция.

Преди търговското предложение да бъде финализирано, купувачите трябва да могат да отговорят на следните въпроси:

Какъв е действителният работен процес на потребителите и операторите на този сайт?

Кое оформление на шкафа, смесица за врати, терминални устройства и условия на място са необходими за този работен процес?

Коя страна притежава софтуер, данни, известия, правила за достъп и обработка на изключения?

Какви чертежи, файлове с протоколи, произведения на изкуството или документи на сайта са налични за преглед?

Кои елементи все още изискват потвърждение от клиента, собственика на сайта или местния екип по проекта?

Този подход е особено важен за-партийни проекти. Един и същ кабинет може да бъде част от жилищен, търговски, кампус, търговски-собственост или оператор-управляван работен процес, но моделът на отговорност няма да бъде същият. Ясният бриф поддържа обхвата на оборудването в съответствие с операцията, която ще го използва.

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

Когато операторът има собствен софтуер или работи с друга платформа, ние можем да прегледаме изискванията на API на контролната платка за заключване или протокола за проекта. Когато се изисква терминален софтуер, управление на облак, информация за състоянието, отчитане, методи за достъп или други функции, действителният им обхват трябва да бъде дефиниран в техническото решение. Това разграничение помага на купувачите да избегнат третирането на предложена опция като универсална характеристика на продукта.