В рамките на дискусионната нишка в LinkedIn на една от последните ми публикации за приложения на ICS, бях подканен да помисля, че още един неудобен елемент за операция EOC може да бъде преходът или интеграцията на изпращане с EOC. Помислете, че по време на „рутинни“ операции изпращането е това, което поддържа полеви операции и проследява критични действия. Много юрисдикции срещат трудности при локално активиране на EOC в подкрепа на нарастващ отговор - какво да правим с изпращането?

Традиционната роля на EOC като „разширена експедиция“ подпомага реагирането на място, като осигурява по-високо ниво на координация далеч отвъд инструментите, които обикновено са на разположение на повечето диспечери, като улеснява директния достъп до представители на агенциите, които са посветени да подкрепят нуждите на инцидента. При рутинни операции Command (или Logistics) се свързва директно с диспечера (обикновено по радио), за да поиска ресурси. При активиране на EOC тези заявки трябва да бъдат насочени към EOC. В някои юрисдикции EOC се намират съвместно с изпращане (поне в същата сграда), което прави този преход малко по-лесен по отношение на технологиите и хората, но някои юрисдикции отделят тези сгради.

Как решавате тази неудобна дилема на интерфейса ICS / EOC? На първо място, трябва да бъде обмислено и планирано ПРЕДИ до инцидент! Това е моментът, в който можем да свършим най-добрата си работа, в идеалния случай да привлечем всички съответни заинтересовани страни към масата, да очертаем процеси и процедури и да идентифицира оборудване и технологични проблеми, необходими за поддържането му. С всички заедно говорете какво искате да направите предвид обстоятелствата, които имате. Всяка идея вероятно има плюсове и минуси, които трябва да бъдат претеглени.

ПРОЧЕТЕТЕ ПОВЕЧЕ БЛИГ НА ТИР РИЕКЪР БЪЛГАРИЯ