Рад са локалним интеграторима на пројектима паметних ормарића: јасан модел сарадње

У ИС ЛОЦКЕР-у видимо да се хардверски разговори одвијају брже када је оперативно питање већ јасно. Шта купац из иностранства треба да дефинише када ће локални интегратор повезати, инсталирати или управљати пројектом паметног-ормана? Циљ није да се да универзално обећање о једном ормару, софтверском пакету или начину инсталације. То је да се иностраним Б2Б купцима пружи дисциплинован начин да дефинишу пројекат пре него што упореде понуде.

Ормарић за пакете је део радног тока. Ток посла укључује оператера, тим за испоруку, тим локације, примаоца, а понекад и засебног софтвера или партнера за интеграцију. Када те улоге нису дефинисане, пројекат може имати изглед кабинета, али не и поуздан договор о примопредаји, изузецима, протоку информација или прихватању. Препоручујемо да снимите очекивани ток посла на једноставном језику и да га третирате као улаз за дизајн.

За улоге добављача и интегратора, испоруку у кабинету, рад на локалном месту, власништво над софтвером, размену протокола, тестирање, ескалацију и контролу промена, најважнији документ је мапа одговорности. Требало би да наведе обим локалног партнера, одговорност за инсталацију, власника платформе, документе о интерфејсу, услове локације, план тестирања, очекивања од обуке и контакте за ескалацију. Ово спречава добављача кабинета, власника платформе, оператера, интегратора и оператера локације да претпостави да друга страна поседује исту функцију.

Многи оператери{0}}ормарица за пакете већ користе сопствени оперативни софтвер или платформу-треће стране. У тим пројектима, ИС ЛОЦКЕР може да обезбеди АПИ за закључавање-контролне плоче или протокол за интеграцију пројекта. Софтвер терминала, брендирање, радни ток испоруке и преузимања, интерфејси сервера и функције управљања такође се могу разговарати у складу са потврђеним обимом пројекта. Не представљамо функције треће стране- или прилагођени софтверски опсег као подразумевану функцију сваког ормарића.

Почните са питањем које је најближе стварном ризику купца. За ову тему, то су улоге добављача и интегратора, испорука у кабинету, рад на локалном сајту, власништво над софтвером, размена протокола, тестирање, ескалација и контрола промена. Направите кратку табелу која наводи тренутно стање, власника који то може потврдити, доступне доказе и одлуку која је још потребна. Ово производи јаснији захтев за понуду и кориснији технички преглед.

Сто не би требало да се заустави на кабинету. Требало би да покрије физички изглед, редослед испоруке и прикупљања, терминалне уређаје где је потребно, услове мреже и напајања, оперативни софтвер и улогу тима на локацији након пуштања у рад. Када функција припада платформи клијента или платформи{2}}треће стране, јасно је идентификујте. Тамо где се ради о-захтеву за прилагођавање специфичном за пројекат, идентификујте га као захтев, а не као стандардни захтев.

Пре него што се комерцијални предлог финализује, купци би требало да буду у могућности да одговоре на ова питања:

Какав је стварни ток рада корисника и оператера на овој локацији?

Који распоред ормара, комбинација врата, терминални уређаји и услови на локацији су потребни за тај ток посла?

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

Који цртежи, датотеке протокола, уметничка дела или документи локације су доступни за преглед?

Које ставке још увек захтевају потврду од стране купца, власника сајта или локалног пројектног тима?

Овај приступ је посебно важан за више{0}}пројекте. Исти кабинет може бити део стамбеног, малопродајног, кампуса, комерцијалне{2}}некретнине или тока посла којим управља оператер{3}}, али модел одговорности неће бити исти. Јасан сажетак одржава обим опреме у складу са операцијом која ће је користити.

Пружамо хардвер за паметне ормариће и можемо да прегледамо-конфигурацију ормара специфичне за пројекат за апликације ормарића за пакете. На основу потврђених захтева пројекта, можемо да разговарамо о распореду ормара и врата, главној-и-подређеној структури, бојама и графици површине, релевантном електронском хардверу, контексту инсталације и границама интеграције софтвера или система{4}}.

Тамо где оператер има сопствени софтвер или ради са другом платформом, можемо да прегледамо АПИ за закључавање-АПИ контролне плоче или захтеве протокола за пројекат. Када се захтевају софтвер терминала, управљање облаком, информације о статусу, извештавање, методе приступа или друге функције, њихов стварни обим мора бити дефинисан у техничком решењу. Ова разлика помаже купцима да избегну третирање предложене опције као универзалне карактеристике производа.