उत्पादन उपकरणांचे निरीक्षण: ते रशियामध्ये कसे चालले आहे?

हॅलो, हॅब्र! आमची टीम देशभरातील मशीन्स आणि विविध इंस्टॉलेशन्सचे निरीक्षण करते. मूलत:, आम्ही निर्मात्याला "अरे, हे सर्व तुटलेले आहे" तेव्हा पुन्हा एकदा अभियंता पाठवू नये अशी संधी प्रदान करतो, परंतु प्रत्यक्षात त्यांना फक्त एक बटण दाबावे लागेल. किंवा जेव्हा ते उपकरणांवर नाही तर जवळपास तुटले.

मूळ समस्या खालीलप्रमाणे आहे. येथे तुम्ही ऑइल क्रॅकिंग युनिट, किंवा मेकॅनिकल इंजिनिअरिंगसाठी मशीन टूल किंवा प्लांटसाठी काही अन्य उपकरण तयार करत आहात. नियमानुसार, विक्री स्वतःच अत्यंत क्वचितच शक्य आहे: हा सहसा पुरवठा आणि सेवा करार असतो. म्हणजेच, तुम्ही हमी देता की हार्डवेअरचा तुकडा 10 वर्षे कोणत्याही व्यत्ययाशिवाय काम करेल आणि व्यत्ययांसाठी तुम्ही आर्थिकदृष्ट्या जबाबदार असाल किंवा कठोर SLA किंवा तत्सम काहीतरी प्रदान कराल.

खरं तर, याचा अर्थ असा आहे की आपल्याला साइटवर नियमितपणे अभियंता पाठवणे आवश्यक आहे. आमच्या सराव दर्शविल्याप्रमाणे, 30 ते 80% सहली अनावश्यक असतात. पहिली केस - दूरस्थपणे काय झाले हे शोधणे शक्य होईल. किंवा ऑपरेटरला दोन बटणे दाबण्यास सांगा आणि सर्वकाही कार्य करेल. दुसरी केस "ग्रे" योजना आहे. जेव्हा एखादा अभियंता बाहेर जातो, बदली किंवा जटिल कामाचे वेळापत्रक तयार करतो आणि नंतर कारखान्यातील एखाद्या व्यक्तीसह नुकसान भरपाई अर्ध्यामध्ये विभाजित करतो. किंवा तो आपल्या शिक्षिका (वास्तविक केस) सह त्याच्या सुट्टीचा आनंद घेतो आणि म्हणूनच त्याला अधिक वेळा बाहेर जायला आवडते. रोपाला हरकत नाही.

मॉनिटरिंग स्थापित करण्यासाठी डेटा ट्रान्समिशन डिव्हाइससह हार्डवेअरमध्ये बदल करणे आवश्यक आहे, स्वतः ट्रान्समिशन, ते संचयित करण्यासाठी काही प्रकारचे डेटा लेक, प्रोटोकॉल पार्स करणे आणि सर्वकाही पाहण्याची आणि तुलना करण्याची क्षमता असलेले प्रक्रिया वातावरण. बरं, या सर्व गोष्टींमध्ये बारकावे आहेत.

आम्ही रिमोट मॉनिटरिंगशिवाय का करू शकत नाही?

हे खूप महाग आहे. एका अभियंत्यासाठी व्यवसाय ट्रिप - किमान 50 हजार रूबल (विमान, हॉटेल, निवास, दैनिक भत्ता). शिवाय, ब्रेकअप करणे नेहमीच शक्य नसते आणि एकाच व्यक्तीची वेगवेगळ्या शहरांमध्ये आवश्यकता असू शकते.

• रशियामध्ये, पुरवठादार आणि ग्राहक जवळजवळ नेहमीच एकमेकांपासून बरेच दूर असतात. तुम्ही सायबेरियाला एखादे उत्पादन विकता तेव्हा, पुरवठादार तुम्हाला जे सांगतो त्याशिवाय तुम्हाला त्याबद्दल काहीही माहिती नसते. ते कसे कार्य करते, किंवा ते कोणत्या परिस्थितीत वापरले जाते, किंवा, वाकड्या हातांनी कोणते बटण कोणी दाबले हे नाही - तुमच्याकडे वस्तुनिष्ठपणे ही माहिती नाही, तुम्हाला ती केवळ ग्राहकांच्या शब्दांतूनच कळू शकते. यामुळे देखभाल करणे खूप कठीण होते.
• निराधार अपील आणि दावे. म्हणजेच, तुमचे उत्पादन वापरत असलेला तुमचा ग्राहक कधीही कॉल करू शकतो, लिहू शकतो, तक्रार करू शकतो आणि म्हणू शकतो की तुमचे उत्पादन काम करत नाही, ते खराब आहे, ते तुटले आहे, तातडीने या आणि ते दुरुस्त करा. जर तुम्ही भाग्यवान असाल आणि फक्त "उपभोग्य वस्तू भरल्या नाहीत" असे नाही, तर तुम्ही तज्ञांना निरर्थक पाठवले नाही. असे बरेचदा घडते की उपयुक्त कामास एका तासापेक्षा कमी वेळ लागतो आणि इतर सर्व काही - व्यवसाय सहल, उड्डाणे, निवास - या सर्व गोष्टींसाठी अभियंताचा बराच वेळ लागतो.
• स्पष्टपणे निराधार दावे आहेत आणि हे सिद्ध करण्यासाठी, तुम्हाला अभियंता पाठवावा लागेल, अहवाल तयार करावा लागेल आणि न्यायालयात जावे लागेल. परिणामी, प्रक्रियेस विलंब होतो आणि यामुळे ग्राहक किंवा तुमच्यासाठी काहीही चांगले होत नाही.
• विवाद उद्भवतात कारण, उदाहरणार्थ, ग्राहकाने उत्पादन चुकीच्या पद्धतीने चालवले आहे, ग्राहकाला काही कारणास्तव तुमच्याबद्दल राग आहे आणि तो म्हणत नाही की तुमचे उत्पादन योग्यरित्या कार्य करत नाही, तांत्रिक वैशिष्ट्यांमध्ये नमूद केलेल्या मोडमध्ये नाही आणि पासपोर्ट मध्ये त्याच वेळी, आपण त्याविरूद्ध काहीही करू शकत नाही किंवा आपण हे करू शकता, परंतु अडचणीसह, उदाहरणार्थ, आपले उत्पादन कसे तरी लॉग केले आणि ते मोड रेकॉर्ड केले. ग्राहकाच्या चुकीमुळे ब्रेकडाउन - हे नेहमीच घडते. माझ्याकडे अशी केस होती की एका खांबाशी टक्कर झाल्यामुळे एक महाग जर्मन पोर्टल मशीन तुटली. ऑपरेटरने ते शून्यावर सेट केले नाही आणि परिणामी मशीन तेथेच थांबली. शिवाय, ग्राहक अगदी स्पष्टपणे म्हणाला: "आम्हाला त्याच्याशी काही देणेघेणे नाही." परंतु माहिती लॉग केली गेली, आणि हे लॉग शोधणे आणि कोणता नियंत्रण प्रोग्राम वापरला गेला हे समजणे शक्य झाले आणि परिणामी ही टक्कर झाली. यामुळे वॉरंटी दुरुस्तीसाठी पुरवठादाराचा खूप मोठा खर्च वाचला.
• नमूद केलेल्या "ग्रे" योजना सेवा प्रदात्याचे षडयंत्र आहे. हाच सर्व्हिस टेक्निशियन सर्व वेळ ग्राहकाकडे जातो. ते त्याला म्हणतात: “ऐक, कोल्या, तुला पाहिजे तसे करू: तू लिहित आहेस की येथे सर्व काही तुटले आहे, आम्हाला नुकसानभरपाई मिळेल किंवा तू दुरुस्तीसाठी एक प्रकारचा झिप आणू. आम्ही हे सर्व शांतपणे अंमलात आणू, आम्ही पैसे वाटून घेऊ. जे काही उरले आहे ते एकतर विश्वास ठेवणे किंवा हे सर्व निष्कर्ष आणि पुष्टीकरणे तपासण्याचे काही क्लिष्ट मार्ग शोधणे, ज्यामुळे वेळ किंवा मज्जातंतू जोडले जात नाहीत आणि यामध्ये काहीही चांगले घडत नाही. कार सेवा वॉरंटी फसवणूक कशी हाताळतात आणि या प्रक्रियेवर किती जटिलता लादतात याबद्दल तुम्हाला माहिती असल्यास, तुम्हाला समस्या अंदाजे समजते.

बरं, डिव्हाइस अजूनही लॉग लिहितात, बरोबर? काय अडचण आहे?

समस्या अशी आहे की जर पुरवठादारांना हे कमी-जास्त समजले की लॉग सतत कुठेतरी लिहिणे आवश्यक आहे (किंवा गेल्या काही दशकांमध्ये समजले आहे), तर संस्कृती आणखी पुढे गेली नाही. महागड्या दुरुस्तीसह प्रकरणांचे विश्लेषण करण्यासाठी लॉगची आवश्यकता असते - मग ती ऑपरेटरची त्रुटी असेल किंवा वास्तविक उपकरणे खराब झाली असेल.

लॉग उचलण्यासाठी, तुम्हाला अनेकदा उपकरणांकडे प्रत्यक्ष संपर्क साधावा लागतो, काही प्रकारचे केसिंग उघडावे लागते, सर्व्हिस कनेक्टर उघडावे लागते, त्यास केबल जोडावी लागते आणि डेटा फाइल्स उचलतात. नंतर परिस्थितीचे चित्र मिळविण्यासाठी त्यांना कित्येक तास सतत पकडा. अरेरे, हे जवळजवळ सर्वत्र घडते (ठीक आहे, एकतर माझ्याकडे एकतर्फी दृष्टीकोन आहे, कारण आम्ही त्या उद्योगांसोबत तंतोतंत काम करतो जेथे निरीक्षण स्थापित केले जात आहे).

आमचे मुख्य ग्राहक उपकरणे उत्पादक आहेत. सामान्यतः, ते एखाद्या मोठ्या घटनेनंतर किंवा फक्त वर्षभराच्या प्रवासाची बिले पाहून काही प्रकारचे निरीक्षण करण्याचा विचार करू लागतात. परंतु बरेचदा नाही, आम्ही पैसे किंवा प्रतिष्ठा गमावलेल्या मोठ्या अपयशाबद्दल बोलत आहोत. "जे काही होईल" याचा विचार करणारे पुरोगामी नेते दुर्मिळ आहेत. वस्तुस्थिती अशी आहे की सामान्यत: व्यवस्थापकाला सेवा कराराचे जुने "पार्क" मिळते आणि नवीन हार्डवेअरवर सेन्सर स्थापित करण्यात त्याला काही अर्थ दिसत नाही, कारण त्याची फक्त दोन वर्षांत आवश्यकता असेल.

सर्वसाधारणपणे, काही क्षणी भाजलेला कोंबडा अजूनही चावतो आणि बदल करण्याची वेळ येते.

डेटा ट्रान्सफर स्वतःच फार भयानक नाही. उपकरणांमध्ये सहसा आधीच सेन्सर असतात (किंवा ते खूप लवकर स्थापित केले जातात), तसेच लॉग आधीच लिहिलेले असतात आणि सेवा कार्यक्रम नोंदवले जातात. तुम्हाला फक्त ते पाठवायला सुरुवात करायची आहे. सामान्य प्रथा म्हणजे काही प्रकारचे मॉडेम घालणे, उदाहरणार्थ, एम्बेड-सिमसह, थेट क्ष-किरण मशीनमधून स्वयंचलित सीडरपर्यंत डिव्हाइसमध्ये, आणि सेल्युलर नेटवर्कद्वारे टेलिमेट्री पाठवणे. सेल कव्हरेज नसलेली ठिकाणे सहसा खूप दूर असतात आणि अलिकडच्या वर्षांत दुर्मिळ झाली आहेत.

आणि मग पूर्वीसारखाच प्रश्न सुरू होतो. होय, आता नोंदी आहेत. पण ते कुठेतरी ठेवले पाहिजे आणि कसे तरी वाचले पाहिजे. सर्वसाधारणपणे, घटनांचे दृश्य आणि विश्लेषण करण्यासाठी काही प्रकारची प्रणाली आवश्यक आहे.

आणि मग आपण मंचावर हजर होतो. अधिक तंतोतंत, आम्ही अनेकदा आधी दाखवतो, कारण पुरवठादारांचे व्यवस्थापक त्यांचे सहकारी काय करत आहेत ते पाहतात आणि टेलीमेट्री पाठवण्यासाठी हार्डवेअर निवडण्याबाबत सल्ला घेण्यासाठी लगेच आमच्याकडे येतात.

बाजार कोनाडा

पाश्चिमात्य देशांमध्ये, ही परिस्थिती सोडवण्याचा मार्ग तीन पर्यायांवर येतो: सीमेन्स इकोसिस्टम (खूप महाग, खूप मोठ्या युनिट्ससाठी आवश्यक असते, सामान्यत: टर्बाइन सारख्या), स्व-लिखित मॅंड्युल किंवा स्थानिक इंटिग्रेटरपैकी एक. परिणामी, जेव्हा हे सर्व रशियन बाजारपेठेत आले, तेव्हा एक वातावरण तयार झाले जेथे सीमेन्स त्याच्या इकोसिस्टमचे तुकडे, Amazon, Nokia आणि 1C विकासासारख्या अनेक स्थानिक इकोसिस्टम होत्या.

आम्ही एक एकीकृत दुवा म्हणून बाजारात प्रवेश केला आहे जो आम्हाला कोणत्याही (ठीक आहे, जवळजवळ कोणत्याही अधिक किंवा कमी आधुनिक) प्रोटोकॉलचा वापर करून कोणत्याही डिव्हाइसवरून कोणताही डेटा संकलित करण्याची परवानगी देतो, त्यावर एकत्रितपणे प्रक्रिया करतो आणि कोणत्याही आवश्यक स्वरूपात एखाद्या व्यक्तीला दाखवतो: यासाठी आमच्याकडे आहे. प्रत्येक विकास वातावरण आणि व्हिज्युअल यूजर इंटरफेस डिझाइनरसाठी छान SDK.

परिणामी, आम्‍ही निर्मात्‍याच्‍या डिव्‍हाइसमधून सर्व डेटा संकलित करू शकतो, तो सर्व्हरवर स्‍टोरेजमध्‍ये संचयित करू शकतो आणि तेथे अलर्टसह मॉनिटरिंग पॅनेल एकत्र करू शकतो.

हे असे दिसते (येथे ग्राहकाने एंटरप्राइझचे व्हिज्युअलायझेशन देखील केले आहे, हे इंटरफेसमध्ये बरेच तास आहे):

आणि उपकरणांचे आलेख आहेत:

इशारे यासारखे दिसतात: मशीन स्तरावर, जर कार्यकारी मंडळावरील शक्ती ओलांडली गेली असेल किंवा टक्कर झाली असेल, तर पॅरामीटर्सचा एक संच कॉन्फिगर केला जातो आणि जेव्हा ते ओलांडले जातात तेव्हा सिस्टम विभाग किंवा दुरुस्ती सेवांना सूचित करेल.

विहीर, सर्वात कठीण गोष्ट म्हणजे प्रतिबंधासाठी त्यांच्या स्थितीवर आधारित नोड्सच्या अपयशाचा अंदाज लावणे. जर तुम्हाला प्रत्येक नोड्सचे संसाधन समजले असेल, तर तुम्ही त्या करारावरील खर्च मोठ्या प्रमाणात कमी करू शकता जेथे डाउनटाइमसाठी पैसे दिले जातात.

सारांश

ही कथा अगदी सोपी वाटेल: बरं, आम्हाला कळले की आम्हाला डेटा, निरीक्षण आणि विश्लेषण पाठवण्याची गरज आहे, म्हणून आम्ही एक विक्रेता निवडला आणि त्याची अंमलबजावणी केली. बरं, तेच आहे, प्रत्येकजण आनंदी आहे. जर आपण आपल्या स्वतःच्या कारखान्यात स्वयं-लिखित प्रणालींबद्दल बोलत असाल तर, विचित्रपणे, सिस्टम त्वरीत अविश्वसनीय बनतात. आम्ही लॉगचे सामान्य नुकसान, चुकीचा डेटा, संकलन, स्टोरेज आणि पावतीमध्ये अपयश याबद्दल बोलत आहोत. स्थापनेनंतर एक किंवा दोन वर्षांनी, जुने लॉग हटविले जाऊ लागतात, जे नेहमी चांगले संपत नाहीत. जरी एक सराव आहे - 10 GB प्रति वर्ष एका मशीनमधून गोळा केले जातात. 10 हजार रूबलसाठी दुसरी हार्ड ड्राइव्ह खरेदी करून हे पाच वर्षांसाठी सोडवले जाते... काही क्षणी असे दिसून येते की हे ट्रान्समिटिंग उपकरणे स्वतःच प्राथमिक नाहीत, परंतु प्राप्त डेटाचे विश्लेषण करण्याची परवानगी देणारी प्रणाली आहे. इंटरफेसची सोय महत्त्वाची आहे. ही सामान्यतः सर्व औद्योगिक प्रणालींची समस्या आहे: परिस्थिती लवकर समजून घेणे नेहमीच सोपे नसते. सिस्टममध्ये किती डेटा दृश्यमान आहे, नोडमधील पॅरामीटर्सची संख्या, मोठ्या प्रमाणात आणि मोठ्या प्रमाणात डेटा ऑपरेट करण्याची सिस्टमची क्षमता हे महत्वाचे आहे. डॅशबोर्ड सेट करणे, डिव्हाइसचे अंगभूत मॉडेल, एक दृश्य संपादक (उत्पादन लेआउट्स काढण्यासाठी).

हे व्यवहारात काय देते याची दोन उदाहरणे देऊ.

1. येथे प्रामुख्याने किरकोळ साखळींमध्ये वापरल्या जाणार्‍या औद्योगिक रेफ्रिजरेशन उपकरणांचे जागतिक निर्माता आहे. कंपनीच्या उत्पन्नापैकी 10% उत्पन्न त्याच्या उत्पादनांच्या सर्व्हिसिंगसाठी सेवा प्रदान करण्यापासून येते. सेवांची किंमत कमी करणे आणि सामान्यत: पुरवठा वाढविण्याची संधी देणे आवश्यक आहे, कारण आम्ही अधिक विक्री केल्यास, विद्यमान सेवा प्रणाली सामना करणार नाही. आम्ही एकाच सेवा केंद्राच्या प्लॅटफॉर्मशी थेट कनेक्ट झालो, या विशिष्ट ग्राहकाच्या गरजांसाठी काही मॉड्यूल्स सुधारित केले आणि सेवा माहितीच्या प्रवेशामुळे कारणे ओळखणे शक्य झाल्यामुळे प्रवास खर्चात 35% कपात झाली. सेवा अभियंत्याला भेट देण्याची गरज न पडता अपयश. दीर्घ कालावधीतील डेटाचे विश्लेषण - तांत्रिक स्थितीचा अंदाज लावा आणि आवश्यक असल्यास, त्वरीत स्थिती-आधारित देखभाल करा. बोनस म्हणून, विनंत्यांना प्रतिसाद देण्याची गती वाढली आहे: कमी फील्ड ट्रिप आहेत आणि अभियंते जलद गतीने कामे करण्यास सक्षम आहेत.
2. यांत्रिक अभियांत्रिकी कंपनी, रशियन फेडरेशन आणि सीआयएसच्या अनेक शहरांमध्ये वापरल्या जाणार्‍या इलेक्ट्रिक वाहनांची निर्माता. इतर सर्वांप्रमाणे, त्यांना खर्च कमी करायचा आहे आणि त्याच वेळी तांत्रिक कर्मचार्‍यांना वेळेवर सूचित करण्यासाठी शहरातील ट्रॉलीबस आणि ट्राम फ्लीट्सच्या तांत्रिक स्थितीचा अंदाज लावायचा आहे. आम्ही रोलिंग स्टॉकमधून एका सिच्युएशन सेंटरमध्ये तांत्रिक डेटा संकलित आणि प्रसारित करण्यासाठी अल्गोरिदम कनेक्ट केले आणि तयार केले (अल्गोरिदम थेट ड्राइव्ह कंट्रोल सिस्टममध्ये तयार केले जातात आणि CAN बस डेटासह कार्य करतात). "ऑसिलोस्कोप" मोडमध्ये बदलणारे पॅरामीटर्स (गती, व्होल्टेज, पुनर्प्राप्त उर्जेचे हस्तांतरण, इ.) रिअल-टाइम ऍक्सेससह, तांत्रिक स्थिती डेटाचा रिमोट ऍक्सेस, रिमोट फर्मवेअर अपडेट्समध्ये प्रवेश दिला. याचा परिणाम म्हणजे प्रवास खर्चात ५०% कपात: सेवा माहितीवर थेट प्रवेश केल्याने अयशस्वी होण्याचे कारण ओळखणे शक्य होते सेवा अभियंत्याला भेट न देता, आणि दीर्घ कालावधीच्या अंतराने डेटाचे विश्लेषण आपल्याला अंदाज लावू देते. तांत्रिक स्थिती आणि, आवश्यक असल्यास, आपत्कालीन परिस्थितीच्या वस्तुनिष्ठ विश्लेषणासह "स्थिती-आधारित" देखभाल त्वरित करा. ग्राहकाच्या गरजेनुसार आणि वेळेवर विस्तारित जीवन चक्र करारांची अंमलबजावणी. ऑपरेटरच्या तांत्रिक वैशिष्ट्यांच्या आवश्यकतांचे पालन करणे, तसेच ग्राहक सेवेची वैशिष्ट्ये (वातानुकूलित करण्याची गुणवत्ता, प्रवेग/ब्रेकिंग इ.) चे निरीक्षण करण्याच्या दृष्टीने त्याला नवीन संधी प्रदान करणे.
3. तिसरे उदाहरण म्हणजे महापालिकेचे. आम्हाला वीज वाचवण्याची आणि नागरिकांची सुरक्षा सुधारण्याची गरज आहे. आम्ही कनेक्टेड स्ट्रीट लाइटिंगचे निरीक्षण, व्यवस्थापन आणि डेटा संकलित करण्यासाठी, संपूर्ण सार्वजनिक प्रकाश पायाभूत सुविधा दूरस्थपणे व्यवस्थापित करण्यासाठी आणि एका नियंत्रण पॅनेलवरून सर्व्हिसिंगसाठी एकच प्लॅटफॉर्म कनेक्ट केला आहे, पुढील कार्यांसाठी उपाय प्रदान करतो. वैशिष्ट्ये: दूरस्थपणे, वैयक्तिकरित्या किंवा गटांमध्ये दिवे मंद करणे किंवा बंद करणे, अधिक कार्यक्षम देखभाल नियोजनासाठी लाइटिंग पॉईंट्समधील अपयशाबद्दल शहर सेवांना आपोआप सूचित करणे, रिअल-टाइम ऊर्जा वापर डेटा प्रदान करणे, देखरेखीसाठी आणि रस्त्यावरील प्रकाश सुधारण्यासाठी शक्तिशाली विश्लेषणात्मक साधने प्रदान करणे. बिग डेटावर आधारित प्रणाली, रहदारी, एअर कंडिशन, इतर स्मार्ट सिटी उपप्रणालींसह एकत्रीकरण यावर डेटा प्रदान करते. परिणाम - स्ट्रीट लाइटिंगसाठी 80% पर्यंत ऊर्जा वापर कमी करणे, बुद्धिमान प्रकाश नियंत्रण अल्गोरिदम वापरून रहिवाशांसाठी सुरक्षितता वाढवणे (रस्त्यावरून चालणारी व्यक्ती - त्याच्यासाठी लाईट चालू करा, क्रॉसिंगवर असलेली व्यक्ती - उजळ चालू करा प्रकाशयोजना जेणेकरून त्याला दुरून पाहिले जाऊ शकते), शहरासाठी अतिरिक्त सेवा प्रदान करणे (इलेक्ट्रिक वाहने चार्ज करणे, जाहिरात सामग्री प्रदान करणे, व्हिडिओ पाळत ठेवणे इ.).

वास्तविक, मला काय म्हणायचे आहे: आज, तयार प्लॅटफॉर्मसह (उदाहरणार्थ, आमचे), आपण देखरेख खूप जलद आणि सहजपणे सेट करू शकता. यासाठी उपकरणांमध्ये बदल करण्याची आवश्यकता नाही (किंवा कमीतकमी, अद्याप कोणतेही सेन्सर आणि डेटा ट्रान्समिशन नसल्यास), त्यासाठी अंमलबजावणी खर्च आणि स्वतंत्र तज्ञांची आवश्यकता नाही. तुम्हाला फक्त समस्येचा अभ्यास करणे आवश्यक आहे, ते कसे कार्य करते हे समजून घेण्यासाठी काही दिवस घालवावे आणि काही आठवडे मंजूरी, करार आणि प्रोटोकॉलबद्दल डेटाची देवाणघेवाण करा. आणि त्यानंतर तुमच्याकडे सर्व उपकरणांवरील अचूक डेटा असेल. आणि हे सर्व Technoserv इंटिग्रेटरच्या सहाय्याने संपूर्ण देशात केले जाऊ शकते, म्हणजेच आम्ही विश्वासार्हतेच्या चांगल्या पातळीची हमी देतो, जी स्टार्टअपसाठी वैशिष्ट्यपूर्ण नाही.

पुढील पोस्टमध्ये मी एका अंमलबजावणीचे उदाहरण वापरून पुरवठादाराच्या बाजूने हे कसे दिसते ते दर्शवेल.

स्त्रोत: www.habr.com