Wprowadzenie
W ramach jednego z moich niedawnych projektów badawczych celem analizy nie było opracowanie wymagań na oprogramowanie (tego typu projekty to najwyżej ok. 70% mojej aktywności) a rozwiązanie pewnych problemów informacyjnych. Z uwagi na ochronę know-how klienta, opis ten został mocno okrojony do istoty problemu oraz metody jego rozwiązania, nie ma tu z oczywistych powodów opisu rozwiązania (ale ważne jest to, że rozwiązanie znaleziono). Wartość jednak ma to, że czytelnik może się tu odnaleźć i sam przekonać, co jest źródłem pewnych problemów, czy i jak można je rozwiązać.
W poniższym tekście pojęcie system odnosi sie do systemu dokumentów i formularzy czyli do informacji i zarządzania nią.
Problem 1
Obsługa zapytań ofertowych dla zarejestrowanych użytkowników, do prostych przypadków istnieje narzędzie on-line do generowania ofert: klient składa zapytanie ofertowe samodzielnie (przez www) lub przez email.
Problemem o którym wspomniałem jest takie ułożenie systemu/formularzy, żeby był względnie uniwersalny. Chciałbym móc wybrać sprzedaż każdego typu elementu, natomiast w pamięci mam przypadki, z którymi do tej pory nie potrafię sobie poradzić. Sprzedajemy zespoły urządzeń (wariant bardziej skomplikowany do opisania). Zespół jako taki ma również swoje akcesoria. Musimy przypisać każdemu zleceniu/podzleceniu numer urządzenia, a w przypadku ich serwisu, np. wymiany kluczowych podzespołów lub elementów dodatkowych, zapisać to w historii tego urządzenia.
Bardzo często projektanci formularzy opisujacych produkt intuicyjnie odtwarzają w tych formularzach opis produktu analogicznie do struktury jego konstrukcji. W efekcie formularze te mają skomplikowaną strukturę i złożone reguły kontrolujące zawartość poszczególnych pól (jeżeli do tego są zachowywane i przywoływane z bazy relacyjnej zapytaniami SQL, to są bardzo kosztowne w wytworzeniu i utrzymaniu). W efekcie powielana jest znaczna część logiki opisującej konstrukcję, która i tak jest opisana w detalach w oprogramowaniu CAD. Analiza pokazała, że w celu wyboru produktu, na formularzu zapytania wystarczy umieścić płaską listę kluczowych, charakterystycznych cech produktu by go zidentyfikować, i na tej podstawie – dla pewności – pokazać np. dokument opis (np. PDF) lub zdjęcie produktu, by dać klientowi pewność, że znalazł i zamawia to co chce. To czy jest to produkt czy też podzespół, przestaje mieć znaczenie. Dlatego bardzo ważne jest opracowanie modelu pojęciowego opisującego produkty i ich (produktów) tak zwane definicje atrybutowe (każdy produkt ma unikalny zestaw atrybutów i ich wartości, jakie go opisują). ,
Problem 2
Usługa montażu urządzenia w powierzonej większej konstrukcji. Ten proces jest u nas nieunormowany, zatarty jest podział obowiązków produkcji/serwis.
To problem wielu firm. Tu także rozwiązaniem jest posiadanie wiedzy o tak zwanym otoczeniu naszego produktu, czyli: do czego służy, komu i czego jest częścią. Każda nietrywialna konstrukcja czy usługa, to część jakiegoś systemu. Jedyną skuteczną metodą zarzadzania swoimi produktami jest pełna wiedza o środowisku w jakim są używane. Jeżeli Wasz produkt lub usługa są częścią większej całości, to bez jej zrozumienia, zarządzanie Waszą ofertą w zasadzie nie jest możliwe: producent butów ma pełną wiedzę o konstrukcji ludzkiej stopy i typowej pogodzie w regionie, konstruktor autobusów o urbanistyce, producent cukierków o kubkach smakowych a producent silników o samochodach. To dlatego posiadanie modelu własnego produktu, wraz z tym gdzie i jak jest wykorzystywany, jest bazą do opracowania modelu pojęciowego i struktur informacyjnych opisujacych produkty i to co sie z nimi dzieje.
Problem 3
Obecnie nie mam wprowadzonych procedur odnośnie zarządzania/wersjonowania naszych produktów.
To typowy problem a rozwiązaniem nie jest ERP, a system CAD i repozytorium projektowe uzupełnione systemem PLM (Product Lifecycle Management, ang. Zarządzani Cyklem Życia Produktu). .
Problem 4
Zarządzanie serwisem. Obecnie dział serwisu jest jednym z działów firmy. Planujemy outsourcing serwisu. Jak wydzielić serwis z firmy?
Wbrew pozorom, outsourcing wybranych usług lub całych działów, czyli ich wydzielenie z firmy bez przerywania bieżącej pracy, wymaga bardzo precyzyjnego planu. Opracowanie tego planu tak, by wdrożenie zmiany nie zaszkodziłem firmie w okresie przejściowym, wymaga bardzo dobrego przygotowania, bo straty finansowe, w tym utrata części klientów, spowodowane nawet okresowym spadkiem jakości obsługi, mogą być nieodwracalne. Takie projekty wymagają: audytu i opracowania mapy aktualnych procesów biznesowych, analizy i opracowania standaryzacji dokumentów i procedur, wdrożenia standardów, przekazanie własności tak uporządkowanych procesów biznesowych innej firmie. Mając opracowane struktury dokumentów i to do czego służą, mapujemy je na role w naszej firmie i w firmie podwykoanwcy/partnera. A to znaczy, że należy opracowac co najmniej szkielet procesów biznesowych partnera 9to-be) i wymusić go w umowie z podwykonawcą. .
Podsumowanie
Systemy informacyjne to nie technologia, ta jest ich nośnikiem. Bez zrozumienia słownictwa, struktur informacyjnych dokumentów (formularze ekranowe to też dokumenty), wdrożenie systemu informatycznego jest niemożliwe lub odbywa sie ogromnych kosztem kolejnych zmian i prototypów. Prowadzenie audytów, analiz i projektowania ma jeden cel: minimalizacja niepewności w projekcie. Niepewności jaką jest jego zakres. Nie jest to żaden waterfall, czyli wielomiesięczne analizy i wdrożenia. To prace przygotowawcze zajmujące pojedyncze tygodnie. Opracowanie standaryzacji i strategii wdrażania zmian w firmie, to metoda na szybkie wdrożenie każdej zmiany, zarówno organizacyjnej jak i w obszarze technologii IT.
Zaprzęganie “zaawansowanej nauki” do takiej pracy buduje pewną małą barierę między mną a klientem, dlatego wymagane jest tu jednak pewne partnerskie projektowe zaufanie:
o ile jeszcze może nie do końca zrozumiałem wszystko co dla nas Pan wyprodukował, to na pewno najważniejszą lekcją jest to (może nie tyle sobie uzmysłowiłem, bo z tyłu głowy to zawsze siedziało, ale sprawa zyskała nowe znaczenie) od czego należy zacząć układać sobie firmę/model biznesowy. Nowym dla mnie podejściem jest rozdzielenie modelu biznesowego na warstwy – użytkową, informacyjną, wykonawczą i to że można a nawet chyba należy je po kolei i z osobna układać. Do tej pory każdy dokument, który chciałem wprowadzić był swoim własnym bytem łączącym parę zadań. Tu zobaczyłem drogę: jak opracować szablony dokumentów i jak zacząć z nich korzystać, tak żeby jako opracowany dokument mógł być skutecznie użyty do wielu różnych zastosowań. Np. to o czym rozmawialiśmy: czy reklamacja różni się od innego typu usługi ? Np. od zamówienia na produkt ? W zasadzie nie, i jest praktycznie tym samym dokumentem ale o innym statusie. O ile jeszcze nie wytworzyłem nic merytorycznego z Pana pracy, tak dała mi pewne zaplecze, inny punkt widzenia w dalszych pracach. Staram się o dofinansowanie w ramach przemysłu 4.0, jeśli uda mi się ten projekt ruszyć, to jest szansa, że jeszcze poproszę o wsparcie 🙂
Elementem tego zaufania jest stosowanie standardów bo, bardzo ważne jest też to, by autor analizy i projektu rozwiązania nie uzależniał od siebie swoich klientów. Jak? Autor analiz i projektów wyrażonych w formie dokumentów, powinien stosować otwarte standardy i przekazać klientowi prawa do opracowanej dokumentacji, w części opisującej jego firmę.
