Niedawno napisał do mnie czytelnik pod jednym z artykułów:
Załóżmy, że realizujemy proces biznesowy: zarządzanie kursami walut. W ramach procesu pracownik musi przygotować plik csv zawierający wyłącznie listę słownikową par walut (np. usdpln, eurpln, eurusd). Nazwa pliku to np bieżącą data. Następnie systemX łączy się z API zewnętrznej platformy i pobiera tabele kursów tych par walut (aktualne i historyczne miesiąc wstecz) i wystawia plik xls zawierający dane: nazwa pary walut, data kursu, wartość kursy) Plik ten system X wysyła do szyby ESB. Szyna przesyła ten plik do systemuY. SystemY wykorzystuje te dane do wyznaczenia wewnętrznych kursów walut wg. ustalonego modelu matematycznego. Wynik obliczeń odkładany jest w bazie danych tego systemu. Na końcu procesu jest pracownik, który wykorzystuje te informacje za pośrednictwem SystemuZ. Wybiera parę walut, określa datę i system zwraca mu wewnętrzny kurs wyznaczony przez SystemY. Technicznie odbywa się poprzez odpytanie systemu Y poprzez jego API. Czyli mamy SystemX, SystemY, SystemZ, pracownika, szynę, plik csv, plix xls, 2XAPI no i przepływ danych (najpierw plików, potem poszczególnych atrybutów) . I jak to wszystkim pokazać żeby było czytelne? (źr.: : Model pojęciowy, model danych, model dziedziny systemu)
Prawdę mówiąc, mniej więcej w takiej formie dostaje materiały od moich klientów.. ;). Co możemy zrobić? Pomyślałem, że dobry reprezentatywny przykład pomoże. Popatrzmy…
Niedawno blady strach padł na użytkowników oprogramowanie SAP AG za sprawą pewnego procesu i wyroku:
Po niedawnym orzeczeniu brytyjskiego Sądu Najwyższego, który potwierdził prawo firmy SAP do naliczania opłat za pośrednie korzystanie z systemów SAP przy użyciu takich aplikacji innych firm jak Salesforce, WorkDay i QlikView, korzystanie pośrednie jest obecnie wymieniane przez klientów firmy SAP jako główna obawa w obszarze zarządzania licencjami SAP i kontrolowania ich kosztów. […] W ostatnich tygodniach ryzyko związane z korzystaniem pośrednim ? dotychczas głównie teoretyczne ? stało się rzeczywistością, która może zmusić wiele przedsiębiorstw do poniesienia milionowych niezabudżetowanych kosztów dodatkowych licencji SAP. (Źródło: Korzystanie pośrednie główną obawą klientów SAP – ERP-view.pl)
Cóż to jest to “korzystanie pośrednie” i w czym problem?
In this instance, the third party systems are accessing the SAP environment, pulling data and often writing it back via a connection to the SAP environment. Here a ?user? must be set up to gain access to the SAP system. On the surface then it can appear like only one user (or a small number of users) is performing actions on the SAP system. In reality though, the ?user? will be performing far more tasks than is possible for a single person to undertake. (Źródło: SAP Audits ? Is it impossible to gauge financial exposure? – IT Asset Knowledgebase)
O co chodzi?
Generalnie chodzi o to, że integrowane ze sobą aplikacje wymieniają dane i “zlecają sobie” usługi, i tu warto wiedzieć co (dane, logika aplikacyjna) jest chronione prawami autorskimi i co stanowi know how. Problem tkwi w poprawnym zdefiniowaniu przedmiotu (obiektu) przetwarzania, przedmiotu prawa autorskiego i tego co stanowi know-how.
USTAWA z dnia 4 lutego 1994 r. o prawie autorskim i prawach pokrewnych mówi:
Art. 1. 1. Przedmiotem prawa autorskiego jest każdy przejaw działalności twórczej o indywidualnym charakterze, ustalony w jakiejkolwiek postaci, niezależnie od wartości, przeznaczenia i sposobu wyrażenia (utwór).
Art. 2. 1. Opracowanie cudzego utworu, w szczególności tłumaczenie, przeróbka, adaptacja, jest przedmiotem prawa autorskiego bez uszczerbku dla prawa do utworu pierwotnego. 2. Rozporządzanie i korzystanie z opracowania zależy od zezwolenia twórcy utworu pierwotnego (prawo zależne), chyba że autorskie prawa majątkowe do utworu pierwotnego wygasły. W przypadku baz danych spełniających cechy utworu zezwolenie twórcy jest konieczne także na sporządzenie opracowania. 2. (1) Ochroną objęty może być wyłącznie sposób wyrażenia; nie są objęte ochroną odkrycia, idee, procedury, metody i zasady działania oraz koncepcje matematyczne.
USTAWA z dnia 16 kwietnia 1993 r. o zwalczaniu nieuczciwej konkurencji, mówi, że:
Art. 11. 4. Przez tajemnicę przedsiębiorstwa rozumie się nieujawnione do wiadomości publicznej informacje techniczne, technologiczne, organizacyjne przedsiębiorstwa lub inne informacje posiadające wartość gospodarczą, co do których przedsiębiorca podjął niezbędne działania w celu zachowania ich poufności.
Tak więc mamy kluczowe pojęcie: utwór oraz know-how. Utworem jest unikalna treść zaś know-how to nieujawnione i chronione (!) informacje (treści) techniczne, organizacyjne lub gospodarcze.
Czym jest owo “pośrednie korzystanie z systemu SAP”? Drugi tekst wyjaśnia: “accessing the SAP environment, pulling data and often writing it back via a connection to the SAP environment. Here a ?user? must be set up to gain access to the SAP system“. Czyli “pobieranie i zapisywanie danych”, użytkownik by mógł “tego dokonać” musi mieć dostęp Systemu SAP.
Jednak sam fakt istnienia dostępu i korzystania z niego, nie oznacza korzystania z cudzych wartości intelektualnych!
Najpierw model takiego przypadku:
Użytkownik bezpośredni Systemu to “standardowy”, licencjonowany użytkownik. Aplikacja pośrednicząca także korzysta z licencjonowanego dostępu (API). Jak, i z czego (i czy), korzysta Użytkownik pośredni Systemu?
Żeby wskazać to, z czego korzysta zewnętrzny użytkownik (aktor) Systemu, należy “zajrzeć” do wnętrza systemu. Architektura Systemu i integracji ma taką postać:
Na tym diagramie mamy trzy kluczowe elementy (tu artefakty) reprezentujące wartości intelektualne chronione prawem: Logika biznesowa, Zebrane dane i Strukturę danych. Logika biznesowa to sposób (metody) przetwarzania informacji (danych) zawarte w programie komputerowym, stanowią (mogą stanowić) know-how firmy, sam program komputerowy (jego treść) to ustalony utwór. Prawo autorskie chroni bazy danych (zebrane i uporządkowane dane) zaś struktura danych (projekt, model danych) to także utwór chroniony.
Zintegrowana z Systemem aplikacja korzysta z API Systemu. API standardowo pozwala np: na pobranie obiektu, wstawienie obiektu oraz wykonanie operacji z użyciem logiki biznesowej.
Zasadnicze pytanie brzmi: co w Systemie stanowi produkt “działalności twórczej o indywidualnym charakterze”? Na pewno jest to oprogramowanie jako takie oraz struktura (model) danych oraz baza danych, czyli zebrane dane (z uwagi na ich unikalną strukturę, model, w bazie danych). Jednak program realizuje określoną logikę biznesową (operacje na danych) i przetwarza określone obiekty biznesowe, czyli określone zestawy danych takie jak faktura czy dokument magazynowy WZ. Ogólnie operacje z użyciem Systemu (aplikacji) mają np. taką postać:
Jest to przykład możliwego dialogu użytkownika (aktor) z aplikacją (System). Dialog taki, niezależnie od stopnia komplikacji, będzie się składał z operacji będących logiką biznesową (czyli specyfiką dziedziny) lub techniczną (specyfiką technologii implementacji). Przedmiotem przetwarzania będą określone obiekty biznesowe (nazwane zestawy danych), komunikat na ekranie także może być takim obiektem (jeżeli tym komunikatem jest treść dokumentu a nie tylko tekst mówiący, że coś zostało wykonane np. bez błędu).
Tu jednak mamy do czynienia z oprogramowaniem wspierającym między innymi operacje opisane w ustawach (księgowe). Niewątpliwie prawo chroni strukturę danych, dane zebrane w bazie danych oraz know-how, to które jest nieznane “innym”. Jednak prawo nie chroni idei, nie chroni też tego co “jest powszechnie znane”. Warto także wiedzieć, że wdrożenie w toku którego miała miejsce tak zwana kastomizacja, “wnosi” know-how przyszłego użytkownika do kodu, i za korzystanie z tej logiki dostawca oprogramowania nie ma prawa brać wynagrodzenia. Pod warunkiem jednak, że kod realizujący to wniesione know-how jest jawnie wydzielony!
Podsumowanie
Nie ma jednoznacznej odpowiedzi na pytanie czy w danym przypadku ma miejsce korzystanie pośrednie z oprogramowania, niewątpliwie sam fakt integracji nie stanowi korzystania pośredniego. Nie jest tez prawdą, ze sam fakt integracji automatycznie implikuje korzystanie pośrednie wymagające opłaty licencyjnej. Kluczem do stwierdzenia tego jest wiedza o architekturze systemu, o architekturze całości integracji i o tym jakie operacje i gdzie są wykonywane. Na szczęście to dostawca Systemu musi uzasadnić swoje roszczenia dotyczące własności intelektualnej, jednak korzystający z tego Systemu – jeżeli nie potrafi podać kontrargumentów – nie jest w stanie się obronić. Niestety największym problemem jest wdrożenie polegające na kastomizacji, gdyż dochodzi do “wplecenia” nowej logiki biznesowej do już istniejącej w dostarczanym oprogramowaniu.
Skutek jest taki, że dostawca oprogramowania ma podstawy prawne do ochrony kodu jaki dostarczył, jednak kupujący nie ma żadnych podstaw (dokumenty, projekt itp.) by chronić swoje know-how i by nie płacić za swoje własne know-how “włożone” w toku wdrożenia, do wdrażanego oprogramowania.
Dlatego warto restrykcyjnie prowadzić proces analizy i projektowania, to jest umiejętnie udokumentować projekt tak, by granica pomiędzy wartościami intelektualnymi dostawcy i nabywcy oprogramowania była jasno określona. I nie jest to rola prawnika a architekta całości systemu, który musi także znać i rozumieć prawne aspekty tej architektury.
Bardzo często spotykam się z projektami inicjowanymi przez średnie kadry kierownicze dużych firm i urzędów, często mają one pewną wspólną cechę: “nie możemy nic zmieniać w strategii organizacji ale chcemy usprawnić pracę w naszym wydziale”. To z reguły bardzo cenna inicjatywa ale także dobra droga do porażki projektu. W urzędach często na granicy łamania prawa… a nie raz z jego łamaniem.
Projekty w administracji publicznej mają dodatkową specyfikę: zasady ustala prawodawca a nie menedżer organizacji. Bardzo dobrze opisał to zjawisko prof. Bolesław Szafrański wskazując przyczynę wielu porażek wdrożeń w administracji. Opisał trzy-etapowy referencyjny (i zalecany) proces wdrażania nowych rozwiązań, a na jego tle, w swoim opracowaniu, wskazał dostrzeżone zaniedbania administracji:
(źr. na podst.: Bolesław Szafrański, Wydział Cybernetyki, Wojskowa Akademia Techniczna, “Architektura korporacyjna ? problemy nie tylko pojęciowe”)
Cytuję to opracowanie, bo model ten jest bardzo podobny do ogólnej trójwarstwowej koncepcji organizacji. Prof Szafrański zwraca uwagę na to (z czym się zgadzam), że kolejność podejmowania decyzji i działań, powinna być następująca: opracowanie nowej lub zmienionej strategii (Dokument strategiczny), opracowanie taktyki działania (Model operacyjny działania) oraz opracowanie planu wdrożenia IT (Fundament działalności, w kontekście Architektury Korporacyjnej). Oczywiście nic nie stoi na przeszkodzie, by inicjatywa wyszła “od dołu”.
W swoim opracowaniu prof. Szafrański wskazuje, że wdrożenie nowej strategii wymaga sprawdzenia i ewentualnego opracowania nowych mechanizmów, procedur, prawa, pozwalającego nie tylko wdrożyć nową strategię ale także skutecznie ją “wymusić”.
Jeżeli powyższy model uogólnić do postaci obrazującej związek pomiędzy: strategią rynkową organizacji, wewnętrzną taktyką realizacji misji oraz tym jak zostały one zaimplementowane, to powstanie taki oto diagram (po prawej znane od lat opracowanie Business Process Trends):
Jeżeli pomiąć formę prawną, każda organizacja ma strategię i każda jakoś ją realizuje (implementuje: ma pracowników a Ci umiejętności i zakresy obowiązków). Mało która organizacja ma tak zwany “model operacyjny”, czyli to co łączy strategię i ludzi z ich obowiązkami i uzyskiwanymi efektami pracy. Czym jest taki model? To model procesów biznesowych: środkowa “warstwa” powyższego diagramu po prawej.
Rozwijające się ewolucyjnie organizacje zawsze dokumentują detale prac (informacje w procedurach zarządzania jakością i tak zwanych dokumentach kadrowych), często dokumentują to, jaką rolą pełni organizacja w swoim otoczeniu (misja, wizja, strategie itp.) i bardzo rzadko dokumentują wewnętrzny łańcuch wartości czyli procesy biznesowe oraz, no najważniejsze, logika tego jak “to wszystko działa” w środku (i czy działa z sensem). Wadą większości tego typu projektów, jakie obserwuję, jest skupianie się na detalach i pomijanie pryncypiów. W efekcie projekt pochłania wiele pracy i nadal nie mamy zrozumienia całości (w lit. ang. “big picture”), osiągane efekty są losowe.
Pokażę na dość prostym przykładzie o czym mowa (polecam ww. opracowanie prof. Szafrańskiego, opisał w nim błędy popełnione w przypadku informatyzacji Państwa).
Poniższy diagram to uproszczony model organizacji z zainstalowanym systemem EOD (Elektroniczny Obieg Dokumentów) oraz zachowanym, nadal wykorzystywanym “po staremu” oprogramowaniem poczty elektronicznej.
Linie ciągłe to droga jaką pokonują dokumenty z użyciem EOD. Linie przerywane to poczta elektroniczna. Jeżeli zostanie w jakiejś organizacji zainstalowany EOD (celowo nie używam słowa “wdrożony”) i nie zostanie z niej usunięty email jako narzędzie alternatywnej wewnętrznej komunikacji, to użytkownik będzie sam decydował, o tym którym kanałem przekaże daną treść. W efekcie EOD, który miał “mieć wszystko” nie ma wszystkiego, dane w EOD są niewiarygodne i niekompletne. Jeżeli jest to urząd, to metryka sprawy w zasadzie nie ma sensu, celem jej tworzenia była możliwość odtworzenia pełnego przebiegu sprawy, a tu urzędnik sam decyduje, które informacje i dokumenty przekazuje kanałem formalnym (EOD), a które “na boku”. Czy wszystko musi być w EOD? Tak. Jeżeli nie jest, EOD jest tylko uznaniowym archiwum dokumentów.
Aby skutecznie wdrożyć EOD należy najpierw opracować nowy model operacyjny działania organizacji, model uwzględniający nowe narzędzie pracy, model który w sposób systemowy wyeliminuje niepożądane elementy “złego starego systemu”. Dla przykładu powyżej należy wyeliminować kanały komunikacyjne oznaczone linią przerywaną. Domyślam się, że wielu czytelników myśli teraz “no jak to tak bez maila?!”. Po wdrożeniu EOD, wewnętrzny mail jest już nie potrzebny (a nawet jest szkodliwy), a na zewnątrz nadal jest narzędziem komunikacji firma-firma (tak np. działa mój system komunikacji z klientami). Bardzo często spotykam urzędy i firmy, w których obieg email i obieg “formalny” to uznaniowość pracowników. Te wdrożenia nie spełniają podstawowej roli systemów EOD: śledzenie spraw, statystyki zajętości pracowników, wychwytywanie wąskich gardeł, łatwe zastępowanie się pracowników, możliwość skontrolowania i przejęcia sprawy w dowolnym momencie, pełna historia wymiany informacji.
Takie wdrożenia to właśnie bardzo często inicjatywy na średnich szczeblach, gdzie mogą powstać decyzje o wydaniu środków na takie wdrożenie, ale nie ma żadnych szans na decyzje o opracowaniu i wdrożeniu zmian operacyjnych w skali organizacji (np. aktualizacja instrukcji kancelaryjnej w urzędzie, bez czego wdrożeni EOD nie ma tu żadnego sensu).
Celowo podałem ten przykład, bo typowym powodem niepowodzeń wdrożeń systemów EOD czy CRM (te systemy mają najgorszą statystykę niepowodzeń, a są bardzo podobne do siebie), jest brak opracowanego i wdrożonego skutecznego nowego operacyjnego modelu działania organizacji “po wdrożeniu”. Takim modelem są modele procesów biznesowych, ale nie w postaci monstrualnych ilości detalicznych diagramów (te są tu do niczego nie przydatne). Nie znam przypadku, by takie “obrazki” się do czegokolwiek przydały. Chodzi o modele sformalizowane, o ściśle ustalonym poziomie gradacji procesów. Ile diagramów “powinno być”? Tylko i aż tyle, ile trzeba do rozwiązania problemu… co opisałem między innymi tu.
Powyższe ma także inny istotny aspekt: planowanie i wdrażanie zmian. Typowy rozwój organizacji przebiega w sposób ewolucyjny, dość powolny. Nie wymaga żadnych dodatkowych zabiegów poza przemyślanym wprowadzaniem nowych, pojedynczych zarządzeń czy drobnych zmian organizacyjnych. Jednak próby wdrożenia znacznych zmian w krótkim czasie, z reguły skutkują nieoczekiwanymi efektami, nie zawsze pożądanymi. “Moda” na re-inżynierię procesów biznesowych w latach 90-tych przeminęła tak szybko jak się pojawiła. Dzisiejszy silnie konkurencyjny rynek nie daje czasu na powolne, ewolucyjne zmiany. Bezpieczne zaś wprowadzanie takich zmian nie jest możliwe bez przygotowania. Opisane powyżej plany operacyjne i ich testy, to nic innego jak właśnie przygotowanie się do takich zmian. Mając dobrze opracowane modele procesów i architektury IT (jako całość Architektura Biznesowa/Korporacyjna), możemy przewidzieć i przetestować, większość skutków planowanych zmian, i powoli ale coraz więcej firm to robi…
Kolejna odsłona w rozwoju oprogramowania CASE firmy Visual Paradigm. Agile, pierwszych katach churra optymizmu, zaczyna troszkę się krystalizować co zauważył już [[Scott Ambler]] 12 lat temu:
Visual-Paradigm to także zestaw narzędzi Agile pozwalających z jednej strony zwinnie zarządzać projektowaniem i projektem (to nie jest to samo) z drugiej nie zaniedbywać analizy i modelowania tam gdzie to jednak pomaga.
Nowe elementy v.13.2.:
Kanban Board to nowe narzędzie pozwalające zarządzać zakresem projektu i jego realizacją. Kanban to opracowana w latach pięćdziesiątych w Japonii metoda sterowania produkcją. Słowo kanban w wolnym tłumaczeniu można w poniższym przypadku oddać jako ?spis widoczny?. Tu praktycznie oznacza to co znamy pod nazwą “backlog” tyle, że wersji “widocznej” jako tablicę postępu prac: bilboard dostępny dla członków zespołu.
User Story Estimation to nowy parametr obiektów “user story”. Generalnie tu (w tym narzędziu) user story to nie “proza użytkownika” a sformalizowana wersja znana jako szablon “ja jako …. chciałbym osiągnąć…. mając do dyspozycji …”, historyjki te są parametryzowane miedzy innymi (teraz) estymacja czasu ich implementacji co bardzo ułatwia zarzadzanie projektem.
Kroki wymagające potwierdzenia, nowa cecha specyfikacji przypadków użycia, bardzo ważna rzecz w specyfikowaniu przypadków użycia to wskazanie tych kroków scenariuszy, które wymagają potwierdzenia przez system.
Szybki podgląd (także zestawienie) historyjek użytkownika, w toku projektu kluczowe jest śledzenie projektu, który nie raz ma setki detali w zakresie, od teraz dysponujemy odpowiednimi zestawieniami i podsumowaniami, to jedyny sposób na sprawne zarzadzanie zakresem projektu.
Makiety ekranów to kolejny bardzo ważny element komunikacji z zamawiającym i definiowaniem zakresu projektu, rozbudowana została paleta elementów i ich cech.
CMMN (Case Management Model and Notation) to notacja opublikowana formalnie w 2014 roku. Notacja BPMN ma za cel modelowanie procesów biznesowych czyli powtarzalnych zachowań organizacji, CMMN to narzędzie do modelowania konkretnych (zidentyfikowanych) aktywności, nie przewidzianych w modelach procesów, także do modelowania proponowanych (zaakceptowanych) rozwiązań, w przypadku gdy dana aktywność stwarza problem.
Zarządzanie plikami w repozytorium TeamWork (serwer) z poziomu przeglądarki diagramów.
Tymczasowe diagramy analizy wpływu. Do tej pory były zawsze zapamiętywane co w dużych projektach skutkowało dużą ich liczbą i przeciążaniem projektu, teraz mogą one być tworzone “w locie” bez konieczności ich zachowywania.
Narzędzie potężnieje z każdą kolejną wersją. Obecnie oferowane jest w dwóch wersjach:
Visual-Paradigm (VP) jako narzędzie adresowane do wspierania procesów inżynierii oprogramowania.
ArchiMetric to rozszerzenie pakietu VP, to narzędzie wspierające prowadzenie analiz systemowych organizacji, szeroko pojętego modelowania architektury biznesowej (korporacyjnej).
W 2005 roku wybrałem to narzędzie całkowicie przypadkowo, kierowałem się czasem od momentu zamówienia do uzyskania licencji, bo działo się w toku bardzo ważnego projektu, w którym nie mogłem sobie pozwolić ani na przerwę ani na znaki wodne “evaluation version” w dokumentach w czasie oczekiwania na licencje. Po tych latach korzystania z VP i porównywania pracy z innymi narzędziami spotykanymi w projektach, nadal mam przekonanie, że nieświadomie dokonałem wtedy chyba najlepszego możliwego wyboru.
Więcej o nowinkach w aplikacji:
Visual Paradigm 13.2 introduces a number of new features, which includes:
Narzędzie, którego używam od 2005 roku (rezygnując wtedy z MS Visio bo toporny i wyrzucając demo EA SPARX bo toporny i niezgodny z UML), staje się coraz lepsze. To co powoduje, że nadal nie planuję zmieniać narzędzia to mega ergonomia pracy, 100% zgodności ze specyfikacjami OMG, a przede wszystkim serwer pracy grupowej VPository, co razem daje mega platformę analityczno-komunikacyjną dla analityka i klienta.
