Пилотният проект за отдалечен достъп проверява дали упълномощен потребител може да изпълни реална сервизна задача в рамките на разрешените права и бюджета на обекта. Предварително определете машината или приложението, участниците, работата по инсталиране, отговорника за поддръжката и критериите за приемане.
Измерете времето от одобрението на услугата до използваема връзка. Тествайте премахването на достъпа и възстановяването след прекъсване на връзката. Запишете разликите, които следващият обект ще трябва да адресира.
NIST Cybersecurity Framework 2.0 свързва решенията за киберсигурност с управлението и резултатите за риска. Инсталирането на продукт е само част от това. Използвайте пилотния проект, за да проверите пригодността за работа, отговорностите, възстановяването и контрола на достъпа. Успешният тест на връзката не доказва готовност за редовна експлоатация.
Какво трябва да докаже един добър пилотен проект
Силният пилотен проект обикновено доказва четири неща:
- упълномощените потребители се свързват без ненужни пречки
- достъпът е контролиран и лесен за управление
- местният оперативен екип може да подкрепи модела
- дизайнът може да се разшири отвъд първия обект или първия случай на употреба
Ако пилотен проект докаже само свързаност, той е твърде тесен.
Започнете с една важна практическа задача
Най-добрият пилотен обхват не е нито твърде малък, нито твърде широк.
Добрите отправни точки включват:
- поддръжка на доставчика за критична група машини
- дистанционно отстраняване на неизправности за една линия
- сигурен достъп за разпределен екип за поддръжка
- един обект, който може да действа като шаблон за бъдещо внедряване
Не се опитвайте да включите всеки потребител, обект и изключение в пилотния проект. Това забавя получаването на полезни резултати и скрива практическата полза.
Уточнете предварително как се определят разходите
Разходите за пилотния проект се определят по-лесно, когато екипът уточни няколко основни данни предварително.
Брой обекти
Дори ако пилотният проект започне само с един обект, имайте предвид колко обекти вероятно ще последват. Това помага да се отдели пилотният дизайн от мисленето за дългосрочно внедряване.
Брой активи или цели за връзка
Избройте приложенията, услугите и устройствата, които трябва да са достъпни. Отделно запишете участващите потребители. Тези количества влияят на различни части от лиценза и инсталирането. Проверете как избраният план отчита всяко от тях.
Потребителски групи
Разделете потребителите на практически групи:
- вътрешни инженери
- персонал по поддръжката
- доставчици или OEM производители
- ръководители и потребители само с права за четене
Различните групи често изискват различни модели на одобрение и достъп.
Хардуерни изисквания
Connect може да работи на съществуваща поддържана система. Включете компютър на място или Orenda Box, когато проектът се нуждае от локално събиране на данни или приложения. Ограничената мрежа все още се нуждае от одобрен път за връзка; добавянето на хардуер не премахва това изискване.
Услуги за поддръжка и внедряване
Много екипи забравят да оценят усилията, необходими за:
- първоначална настройка
- дизайн на политиката
- включване в обекта
- включване на доставчика
- обучение за администратори
Тези услуги често са това, което прави пилотния проект използваем в реални операции.
Критерии за успех, от които ръководството всъщност се интересува
Не спирайте до технически проверки като „успешно свързване на потребител“.
По-добрите критерии за успех на пилотния проект включват:
Скорост на достъп
Колко време е нужно за одобрение на реална сервизна заявка и предоставяне на достъп?
Оперативна използваемост
Могат ли поддръжката, инженерният екип и местното ръководство да следват процеса без постоянна помощ?
Качество на управлението
Може ли екипът да отговори ясно:
- кой има достъп
- какво могат да достигнат
- кой е одобрил достъпа
- кога трябва да свърши
По-кратък престой или по-бърза реакция
Съкращава ли подходът диагностиката, времето за включване на доставчика или общото време до решаване на проблема?
Готовност за разширяване
Може ли същият модел да се повтори на следващия обект с ограничен редизайн?
Тези мерки превръщат пилотния проект в решение за внедряване.
Планирайте внедряването още по време на пилотния проект
Честа грешка е пилотният проект да се разглежда отделно от бъдещото внедряване. Определете още по време на пилотния проект как ще продължи разширяването.
План за:
- какво се променя при преминаване от пилотния проект към редовна експлоатация
- кои шаблони могат да се използват повторно
- как ще бъдат включени нови обекти
- как доставчиците ще бъдат добавени или премахнати
- как се осигурява поддръжката след въвеждане в експлоатация
Това предотвратява познатия проблем, при който успешният пилотен проект все още трябва да бъде преработен, преди някой да може да го мащабира.
Прост план за пилотния проект
Ето една практична структура, която много екипи могат да използват.
Стъпка 1: изберете първия обект
Изберете обект с реална нужда и местен екип, готов да съдейства. Задачата трябва да е достатъчно важна, за да бъдат използвани резултатите.
Стъпка 2: дефинирайте един или два сценария за достъп
Примери:
- достъп на доставчика за поддръжка до линия за опаковане
- дистанционен инженерен достъп до една контролна среда
Стъпка 3: запишете началното състояние
Запишете сегашния процес:
- как се иска достъп
- колко време отнема
- къде възникват забавяния
- какви рискове и затруднения има
Стъпка 4: стартирайте пилотния проект в реални операции
Тествайте модела по време на реална поддръжка, а не само на лабораторна демонстрация.
Стъпка 5: преглед на пилотните резултати
Сравнете пилотния проект с базовата линия, след което решете какво трябва да бъде стандартизирано за внедряване.
Чести грешки при пилотни проекти
Няма ясен отговорник от бизнеса
Без отговорник за резултата пилотният проект остава технически тест. Често след него няма решение за внедряване.
Неясен обхват
Ако екипът не може да каже точно кои потребители, активи и работни потоци са в обхвата, цените и резултатите стават неясни.
Игнориране на анулиране и преглед
Управлението трябва да се тества по време на пилотния проект, а не да се добавя по-късно.
Няма предположения за разпространение
Без план за редовна експлоатация пилотният проект често остава еднократна инсталация.
Къде може да помогне Orenda?
Пилотният проект се обосновава по-лесно, когато разходите и внедряването са част от реалистичен план. Решете отрано дали е достатъчна софтуерна инсталация, дали е нужен локален edge компонент и как ще се управлява достъпът след пилотния проект.
Orenda помага на екипите да структурират пилотни проекти около реални случаи на оперативна употреба вместо еднократни демонстрации. Това включва защитен отдалечен достъп, работни процеси на доставчици и внедрявания, които може да изискват локален компонент като Orenda Box.
Ако сега сравнявате пилотни опции, прегледайте Ценообразуването заедно с Решението за защитен отдалечен достъп, така че техническият дизайн и търговският план да останат в съответствие.
Определяте ли сега обхвата на пилотен проект?
Планирате пилотен проект, който да премине в редовна работа? Започнете от Цени. Ако е нужна локална инфраструктура, разгледайте и Orenda Box, преди да определите окончателния обхват.
Запишете крайното решение
Сравнете работата по настройката, реакцията на поддръжката и тестовете за достъп с договорените критерии. След това решете: внедряване, корекция и повторен тест, или промяна на подхода. За всеки отворен въпрос определете отговорник и условие за приключване, преди да добавите следващия обект.
