როცა კარგი პროცესები წყვეტს მასშტაბირებას: ქონების მართვის თვითშეფასება

ზრდა ყოველთვის ცუდ პროცესებს არ ანგრევს. საკმაოდ ხშირად, ის კარგი პროცესების ზღვარს ააშკარავებს.

ქონების მმართველ კომპანიას შესაძლოა ჰყავდეს გამოცდილი გუნდი, საიმედო რუტინა, დიდი ხნის ურთიერთობა მობინადრეებთან და კონტრაქტორებთან, და მუშაობის წესი, რომელმაც წლების განმავლობაში კარგად გაართვა თავი. აშკარად არაფერია არასწორად. განაცხადები მუშავდება, ინვოისები იგზავნება, მობინადრეებმა იციან, ვის დაუკავშირდნენ, და მმართველებმა იციან, როგორ გადაწყვიტონ პრობლემა, როცა ის ჩნდება.

შემდეგ პორტფელი იზრდება. მეტი შენობაა, მეტი მობინადრე, მეტი განაცხადი, მეტი კონტრაქტორი და მეტი ადამიანი, ჩართული ყოველ გადაწყვეტილებაში. რაც ადრე გამოცდილებითა და პირადი კოორდინაციით მუშავდებოდა, ახლა მეტ დროს იტაცებს. ინფორმაციის მიდევნება რთულდება. პროცესი, რომელიც სამ შენობაზე იდეალურად მუშაობდა, ათზე გასაკვირად მყიფე ხდება.

სწორედ აქ ხდება სასარგებლო საოპერაციო სიმწიფის იდეა. ეს ქონების მმართველი კომპანიების „თანამედროვედ“ და „მოძველებულად“, ან „კარგად“ და „ცუდად“ დაყოფას არ ეხება. ეს ეხება იმის გააზრებას, ოპერაციის რა ნაწილი გახდა განმეორებადი სისტემა, და რა ნაწილი ჯერ კიდევ ინდივიდუალურ ძალისხმევაზეა დამოკიდებული.

ამ იდეას ვიკვლევთ წიგნში From Night Alarms to 24/7 Digital Resilience, რომელიც განიხილავს გადასვლას რეაქტიული ქონების მართვიდან სტრუქტურირებულ ციფრულ ოპერაციებამდე. წაიკითხეთ ან ჩამოტვირთეთ From Night Alarms to 24/7 Digital Resilience

წიგნის უკან მდგარი ერთ-ერთი კითხვა მარტივია: რომელი რუტინა, რომელმაც კომპანია მის ამჟამინდელ ზომაზე წარმატებული გახადა, კვლავ იმუშავებს შემდეგზე?

კომუნიკაცია ჩვეულებრივ მუშაობს, სანამ მოცულობა არ შეიცვლება

უმეტესმა გამოცდილმა ქონების მმართველმა უკვე იცის, რამდენად მნიშვნელოვანია კომუნიკაცია. მობინადრეებმა უნდა იცოდნენ, სად წავიდნენ პრობლემით, ისინი პასუხს ელოდებიან და უნდათ, ესმოდეთ, რა ხდება, როცა რაღაცას დრო სჭირდება.

საკითხი იშვიათად ისაა, არსებობს თუ არა კომუნიკაცია. უფრო საინტერესო კითხვაა, როგორ არის ის ორგანიზებული.

თუ მობინადრეთა რაოდენობა ხვალ გაორმაგდებოდა, შეძლებდა გუნდი, იგივე დონის რეაგირება შეენარჩუნებინა, სტრესის გაორმაგების გარეშე? ყველა ერთსა და იმავე კომუნიკაციის ისტორიაზე მუშაობს, თუ კონტექსტის ნაწილი ერთი მმართველის ტელეფონში ან ფოსტაშია? თუ ეს ადამიანი შვებულებაში წავა ან კომპანიას დატოვებს, შეძლებს თუ არა სხვა ვინმე, საუბარი განაგრძოს, მობინადრისთვის ყველაფრის ხელახლა ახსნის თხოვნის გარეშე?

კომუნიკაციის პროცესს ძალიან ძლიერი შეიძლება ეგონოს თავი, სწორედ იმიტომ, რომ მას წარმართავენ ხალხი, ვინც კარგად ასრულებს თავის საქმეს. მაგრამ როცა უწყვეტობა მთლიანად კონკრეტულ თანამშრომლებზეა დამოკიდებული, ზრდა ამ დამოკიდებულებას სულ უფრო ძვირად აქცევს.

წიგნი ამავე განსხვავებას ასე აღწერს: სტაბილურ და მასშტაბირებად პროცესს შორის განსხვავება, ინდივიდუალურ ძალისხმევას შეუძლია, შესანიშნავი სერვისი შექმნას, მაგრამ სტრუქტურა არის ის, რაც ამ ხარისხს ზრდის დროს გადარჩენის საშუალებას აძლევს.

იგივე ეხება სერვისის განაცხადებსაც

ქონების მმართველი გუნდები უზარმაზარ პრაქტიკულ ცოდნას აგროვებენ. გამოცდილ მმართველს ხშირად თითქმის ინსტინქტურად ესმის, ვინ უნდა გადაწყვიტოს კონკრეტული პრობლემა, რომელი კონტრაქტორია საიმედო და რომელი საკითხი მოითხოვს დაუყოვნებელ ესკალაციას.

ეს გამოცდილება აქტივია. სირთულე მაშინ იწყება, როცა ორგანიზაციას მისი დანახვა ან ხელახლა გამოყენება არ შეუძლია.

შეგიძლიათ, თანმიმდევრულად ადევნოთ თვალი განაცხადს, მისი მოსვლის მომენტიდან გადაწყვეტამდე? შეგიძლიათ, ნახოთ, სად ჩვეულებრივ ჩნდება დაგვიანება? შეგიძლიათ, შეადაროთ, რა ხდება რამდენიმე შენობაში, თითოეულის ცალ-ცალკე გამოძიების ნაცვლად?

თუ პასუხი დამოკიდებულია იმაზე, ვინმეს ახსოვს თუ არა შემდგომი მოქმედება, ამოწმებს თუ არა მესენჯერის ნაკადს, ან ეკითხება თუ არა კოლეგას, რა მოხდა, სერვისმა შესაძლოა ისევ იმუშაოს, მაგრამ მისი მუშაობის შენარჩუნების ხარჯი პორტფელთან ერთად იზრდება.

საოპერაციო სიმწიფე გამოცდილების პროგრამული უზრუნველყოფით ჩანაცვლებას არ ნიშნავს. ეს ნიშნავს, გამოცდილება პროცესად ვაქციოთ, რომელსაც სხვა ადამიანებიც შეძლებენ, მიჰყვნენ, და რომელსაც კომპანია რეალურად შეძლებს, გააანალიზოს. წიგნის თავდაპირველი ჩარჩო ზუსტად ამ განსხვავებას აკეთებს გუნდს შორის, ვინც იცის, როგორ გადაწყვიტოს პრობლემები, და სისტემას შორის, რომელიც ამ გადაწყვეტილებებს ხილულსა და განმეორებადს ხდის.

ბილინგსაც იგივე პრობლემის საკუთარი ვერსია აქვს

ბილინგის პროცესი შესაძლოა სრულყოფილად ზუსტი იყოს და მაინც რთულად მასშტაბირებადი. აქ სასარგებლო კითხვები არა მხოლოდ ის არის, სწორად არის თუ არა ინვოისები გამოთვლილი. ესენია ისიც, ესმით თუ არა მობინადრეებს ამის უკან მდგარი ლოგიკა, შესაძლებელია თუ არა ახალი სერვისის დამატება, დიდი ხელით სამუშაოს შექმნის გარეშე, და რა ხდება, როცა კორექტირებაა საჭირო.

როცა პორტფელი და სერვისის მოდელები რთულდება, სხვაობა ზუსტ ბილინგის სისტემასა და მოქნილს შორის სულ უფრო მნიშვნელოვანი ხდება. ფიქსირებული დარიცხვების ნაკრებზე დაპროექტებულმა პროცესმა შესაძლოა წლები იმუშაოს. მაგრამ თუ ყოველი ცვლილება კიდევ ერთ ცხრილს, ხელით გადათვლას ან სამუშაო გვერდით გზას მოითხოვს, ზრდა სიზუსტეს ადმინისტრაციულ ტვირთად აქცევს.

ახლის დამატება დანარჩენს არ უნდა ურთულებდეს

ეს განსაკუთრებით მაშინ ჩანს, როცა მმართველ კომპანიას სურს, ახალი მობინადრის სერვისი, გადახდის მეთოდი, წვდომის სისტემა, დაჯავშნის ინსტრუმენტი ან სხვა ციფრული ფუნქცია დანერგოს. თითქმის ყველაფერი ტექნიკურად შესაძლებელია. უკეთესი კითხვაა, რამდენად რთულია მისი დამატება.

მოითხოვს თუ არა ყოველი ახალი სერვისი კიდევ ერთ დამოუკიდებელ სისტემას? უწევს თუ არა გუნდს, კიდევ ერთი მონაცემთა ბაზა შეინარჩუნოს, ან იმავე ინფორმაცია რამდენჯერმე გაიმეოროს? მოქმედებს თუ არა ინტეგრაცია იმ სამუშაო პროცესებზე, რომლებიც უკვე მუშაობდა?

თუ ყოველი გაუმჯობესება ოპერაციას რთულს ხდის, შეზღუდვა შესაძლოა არა გუნდის ინოვაციური უნარი იყოს, არამედ უბრალოდ, მისი ქვეშ მდებარე არქიტექტურა.

ამიტომ ხდება მოდულურობა ქონების მართვაში სულ უფრო მნიშვნელოვანი. მოწიფულ ოპერაციას უნდა შეეძლოს ევოლუცია, ყოველი ახალი მოთხოვნის გამოჩენისას საკუთარი თავის ხელახლა აშენების გარეშე.

და შემდეგ არის ის ნაწილი, რომლის გაზომვაც ყველაზე რთულია: გუნდი

ძლიერი მმართველები ძალიან კარგად მალავენ სუსტ სისტემებს.

ისინი იმახსოვრებენ. ისინი ადევნებენ თვალს. ისინი იციან, ვის უნდა დაურეკონ. ისინი ამჩნევენ, როცა რაღაც დავიწყებულია, და აგვარებენ, სანამ ეს მობინადრისთვის ხილული გახდება.

გარედან, ოპერაცია შესაძლოა სრულყოფილად ეფექტური ჩანდეს.

ხარჯი სხვაგან ჩნდება: მუდმივ კოორდინაციაში, ჩატებში მიღებულ ზედმეტ გადაწყვეტილებებში, დღის განმავლობაში წყვეტებში და შეგრძნებაში, რომ ყველაფერი მუშაობს, სანამ სწორი ხალხი აგრძელებს ერთმანეთის ხელში დაჭერას.

ეს დიდხანს შეიძლება იყოს მდგრადი. უბრალოდ, ის უფრო რთული ხდება მდგრადობის შენარჩუნება, ბიზნესის ზრდასთან ერთად.

ციფრული ინფრასტრუქტურის მიზანი ამ ხალხის პროცესიდან ამოღება არ არის. ეს არის, შევწყვიტოთ მათი ყურადღებისა და მეხსიერების გამოყენება იმ სამუშაოსთვის, რომელსაც სისტემას შეუძლია აზიდვა. როგორც წიგნის ჩარჩო ამბობს, როცა პროცესები ძირითადად ადამიანებში ცხოვრობს, სისტემებში ცხოვრობის ნაცვლად, ზრდა დაღლილობას ზრდის, ბერკეტის შექმნის ნაცვლად.

მაშ, რამდენად მოწიფულია თქვენი ოპერაცია?

არ არსებობს ერთი წერტილი, სადაც ქონების მმართველი კომპანია „ციფრულად მოწიფული“ ხდება. კომპანიას შეუძლია, ბილინგში მაღალი სტრუქტურირებულობა ჰქონდეს და მაინც მთლიანად ხელით კოორდინაციაზე იყოს დამოკიდებული სერვისის განაცხადებში. კომუნიკაცია შესაძლოა ლამაზად მასშტაბირდებოდეს, მაშინ როცა ახალი სერვისის დანერგვა ზედმეტად რთული რჩება.

სწორედ ამიტომ ვაქციეთ წიგნის საოპერაციო სიმწიფის ჩარჩო ცალკე საოპერაციო სიმწიფის შემოწმებად.

ის შეიცავს 18 კითხვას ხუთ სფეროზე: კომუნიკაცია, სერვისის დამუშავება, ბილინგი, სერვისის გაფართოება და გუნდის დატვირთვა. ყოველი განაცხადი 0-დან 2-მდე ფასდება, ჯამური ქულით 0-დან 36-მდე.

რიცხვი სასარგებლოა, მაგრამ ის რეალურად ყველაზე მნიშვნელოვანი ნაწილი არ არის.

უფრო მნიშვნელოვანია იმის შემჩნევა, სად ჩნდება ყველაზე დაბალი ქულები. ეს ხშირად ის ადგილებია, სადაც კომპანია უკვე ანაზღაურებს სტრუქტურულ შეზღუდვებს დამატებითი დროით, ყურადღებითა და ხელით სამუშაოთი, და სადაც ზრდას ყველაზე დიდი შანსი აქვს, შემდეგში ზეწოლა შექმნას.

შეგიძლიათ, შემოწმება თავად შეავსოთ, მაგრამ შესაძლოა კიდევ უფრო სასარგებლო იყოს, ის გუნდის სხვა წევრთან ერთად შეავსოთ. თუ ორი ადამიანი ერთსა და იმავე კითხვას ძალიან განსხვავებულად პასუხობს, თავად ეს განსხვავება უკვე სასარგებლო ინფორმაციაა.

ჩამოტვირთეთ საოპერაციო სიმწიფის შემოწმება

და თუ შეფასება კითხვებს აჩენს იმის შესახებ, როგორ გადავიდეთ კონკრეტული პროცესი ხელით კოორდინაციიდან უფრო მასშტაბირებად სტრუქტურაზე, დაგვიკავშირდით. ეს ზუსტად ის საოპერაციო პრობლემაა, რომლის გადასაწყვეტადაც Unitify ავაშენეთ.