“Problemy, w których rozwiązaniu mają pomóc budowane złożone systemy są zwykle ?problemami złośliwymi? (Rittel i Webber, 1973). ?Problem złośliwy? to taki skomplikowany problem, w którym jest tak wiele powiązanych ze sobą bytów, że nie istnieje jego ostateczna specyfikacja. Prawdziwy charakter problemu objawia się dopiero w miarę opracowywania rozwiązania.”

Usługa ta stanowi sobą audyt treści i struktury dokumentów w procesach biznesowych oraz opracowanie modelu architektury IT w celu mapowania dokumentów na aplikacje, w których powstają i są wykorzystywane (integracja). Są to wyłączone i połączone razem pierwsze etapy usług Audyt organizacji, podnoszenie efektywności oraz Analiza i Opracowanie Wymagań na Oprogramowanie. Jednym z głównych celów i produktów jest opracowana strategia cyfryzacji i archiwizacji dokumentów w organizacji oraz zarządzania ich treścią.

Wprowadzenie

Bardzo często można się spotkać z opracowaniami zawierającymi w tytule “Studium wykonalności” (o ile sprawdziłem, słowo wykonywalności jest językowo gorsze ;)). Opracowania te są jednak często tylko “dowodem słuszności pomysłu” (lub próbą takiego dowodu).

Studium wykonalności opisuje produkt lub efekt organizacyjny, jakiego oczekujemy oraz to czy jest możliwe wytworzenie tego produktu lub osiągnięcie oczekiwanego efektu organizacyjnego. Ocena rentowności oraz tego tego czy pozyskamy finansowanie na projekt, to nie wykonalność produktu a zdolność do sfinansowania jego powstania i utrzymania.  To drugie to analiza ekonomiczna i finansowa.

Popatrzmy na definicję zamieszczoną np. na Portalu Funduszy Europejskich:

Studium wykonalności (Feasibility study): Studium przeprowadzone w fazie formułowania projektu, weryfikujące, czy dany projekt ma dobre podstawy do realizacji i czy odpowiada potrzebom przewidywanych beneficjentów. Studium powinno stanowić plan projektu. Muszą w nim zostać określone i krytycznie przeanalizowane wszystkie szczegóły operacyjne jego wdrażania, a więc uwarunkowania handlowe, techniczne, finansowe, ekonomiczne, instytucjonalne, społeczno-kulturowe oraz związane ze środowiskiem naturalnym. Studium wykonalności pozwala na określenie rentowności finansowej i ekonomicznej, a w rezultacie tworzy jasne uzasadnienie celu realizacji projektu1. .

Jest to właśnie przykład (wytłuszczenie moje) sprowadzenia studium wykonalności do poziomu “uzasadnienia jego realizacji”, a nie taki ma ono – studium wykonalności – pierwotnie cel.

Studium takie zleca (powinien) sponsor projektu, do którego ktoś przynosi projekt (opis projektu) z prośbą o jego sfinansowanie (o ile projekt nie zawiera już takiej analizy). Samo podjęcie przeprowadzenia studium wykonalności już sugeruje, że należy założyć, że opisany projekt może być “niewykonalny” Studium jest oceną wykonalności, a nie jego stwierdzeniem. Gdyby było inaczej, takie analizy nie miały by sensu, lub były by one tylko udokumentowanym rachunkiem stopy zwrotu z inwestycji (patrz wytłuszczenie w powyższym cytacie). Pan Michał Trocki (Kolegium Zarządzania i Finansów SGH) w Kompleksowa ocena projektów, pisze:

Na wykonalność projektu składa się pięć podstawowych elementów określanych angielskim akronimem TELOS, a mianowicie wykonalność: technologiczna i systemowa (ang. Technology and system feasibility), ekonomiczna (ang. Economic feasibility), prawna (ang. Legal feasibility), operacyjna (ang. Operational feasibility) i czasowa (ang. Schedule feasibility). Dodatkowo w studium wykonalności powinny być brane pod uwagę: wykonalność rynkowa i dotycząca nieruchomości (ang. Market and real estate feasibility), wykonalność zasobowa (ang. Resource feasibility) oraz wykonalność kulturowa (ang. Cultural feasibility). Wykonalność projektu oceniana jest ex ante.2

Celem sponsora projektu jest podjęcie decyzji, a co do zasady, z perspektywy scenariuszowych metod zarządzania i analizy systemowej, decydent powinien mieć wybór (w przeciwnym wypadku nie jest decydentem). Aby dokonać wyboru, decydent powinien znać co najmniej dwa możliwe rozwiązania i ryzyka z nimi związane. PARP w swoich zalecaniach do Studium wykonalności we wstępie pisze:

Zadaniem tworzącego studium wykonalności jest wybór takiego rozwiązania techniczno-technologicznego, które nie dość, że umożliwi realizację postawionych wcześniej celów, przyczyni się do rozwiązania problemów zidentyfikowanych w danej jednostce, to jeszcze wykorzystywać będzie istniejące zasoby i środki oraz zagwarantuje trwałość wybranego rozwiązania nie tylko w okresie, w którym możliwa jest kontrola wydatkowanych środków, ale również po jego zakończeniu.3

W zaleceniach tych znajdujemy, że studium (Wykonalność techniczna-technologiczna) powinno zawierać między innymi: Najważniejsze warianty realizacji projektu (inne możliwe sposoby osiągnięcia celu projektu). 3

Kluczowe pojęcia

Popatrzmy na znaczenie słów studium i wykonalność:

studium 1. ?rozprawa naukowa na określony temat?, 2. ?drobiazgowa analiza czegoś przedstawiona w książce lub filmie?, 3. ?dzieło niemające charakteru wykończonej kompozycji, będące pracą przygotowawczą?, 4. ?wydział wyższej uczelni; też: samodzielna szkoła wyższa lub policealna?

wykonalny: 1. ?możliwy do wykonania?, 2. praw. ?taki, który musi być wykonany? (źr. www.pwn.pl)

W przypadku słowa studium interesują nas tu (z oczywistych chyba powodów) dwa pierwsze, w przypadku słowa wykonalny – pierwsze znaczenie.  Tak więc:

Studium wykonalności to drobiazgowa analiza możliwości wykonania czegoś.

i jest to definicja wynikająca wyłącznie ze znaczeń tych słów, co ciekawa jest zgodna z [[ogólną teorią systemów]] i analizą systemową (analiza systemowa). Analiza taka, z perspektywy decydenta jest “sprawdzeniem” i pojawia się tu często słowo “ewaluacja”, które jednak budzi moje wątpliwości z wyżej opisanych powodów. Znaczy ono: ewaluacja ?określenie wartości czegoś? (s.j.p. PWN).

Czym jest (powinna być) analiza wykonalności

Generalnie jest to ocena szans na realizację przedsięwzięcia. Popatrzmy na poniższy diagram:

studium_wykonalnosci

Widzimy: hipotetyczny zerowy stan początkowy, jakiś określony stan aktualny (nasza obecna sytuacja), planowany stan oraz sytuację idealną czyli stan nieprzekraczalny (ale teoretycznie możliwą). Nasz projekt może polegać na poprawie (rozwoju) czegoś (punktem startu jest stan aktualny), lub także wytworzeniem (punktem startu jest wtedy stan początkowy). Z perspektywy analizy wykonalności nie ma to znaczenia. Istotny jest stan planowany i stan idealny. Do czego nam potrzebna wiedza (znajomość) o stanie idealnym?

Stan idealny4 (o ideałach pisałem tu: Utopia – model ideału pomaga w projektach) to kluczowy element analizy wykonalności, gdyż stanowi drugi, po punkcie początkowym, punkt oparcia do wyliczenia (oceny) postępu (wyrażonego np. w procentach) jaki chcemy uczynić. Planowany do osiągnięcia efekt jest nie możliwy do oceny ryzyka, jeżeli nie znamy zakresu w jakim się poruszamy. Wielu analityków uważa, że nie ma problemu w sytuacji, gdy intuicyjnie wiemy, że ten zakres jest znacznie większy od postępu jaki chcemy poczynić a my jesteśmy daleko od ideału. Czy tak jest? Czy faktycznie mam taką wiedzę?

Niestety intuicja może być bardzo myląca. Jeżeli nie wiemy jaka jest zależność pomiędzy wymaganymi nakładami a osiągalnym efektem, to jest nie mamy modelu tego co ulepszamy, nie znamy teorii jaka opisuje dane zjawisko lub sytuację, możemy nie wiedzieć, że zależność ta jest np. silnie nieliniowa (a z reguły tak jest), i że osiągnięty – czasem łatwo – stan obecny leży na załamaniu krzywej tej zależności. To typowa sytuacja, w której heurystyka (dotychczasowe doświadczenie) jest zgubna dla projektu. Tak właśnie “są rozkładane” projekty planowane metodami analizy trendu i na bazie “dotychczasowych doświadczeń”.

Brak wiedzy o stanie idealnym możliwym i brak modelu, czyni analizę wykonalności bardzo ryzykowną, więc praktycznie bezwartościową.

Przykładów jest wiele, np. osiągnięcia sportowców (relatywnie łatwo osiąga się wyniki ponad średnią, bardzo trudno poprawić je dalej o pojedyncze procenty by zdobyć medal na olimpiadzie), osiągane udziały w rynku (pierwsze inwestycje w reklamy z reguły przynoszą pozytywne efekty, nie raz bardzo często, firmie będącej w czołówce rynku, łatwo poprawić wyniki o pojedyncze procenty, czasem jedynym sposobem dalszego są jednak już tylko przejęcia co widać na rynku).

Dlatego poprawnie wykonana analiza wykonalności powinna zawierać:

  1. opis stanu obecnego,
  2. opis (model) stanu idealnego,
  3. model opisujący system (teoria opisująca środowisko) w jakim funkcjonuje ulepszany przedmiot (i jego miernik), w tym zależność nakładów vs. postęp,
  4. deklaracje planowanego postępu (mierzalny cel projektu),
  5. ocenę (ryzyko) wykonalności planowanego celu, warianty alternatywne (np. minimalny satysfakcjonujący i najlepszy na jaki nas stać).

Zakończenie

W literaturze można spotkać różne “definicje” studium wykonalności, jednak ta którą opisałem, zdaje się być najbliższa definicji, którą przytoczyłem na początku: bazującej na znaczeniu słownikowym. Praktyka pokazuje, że intencje sponsorów tych analiz są z nią zbieżne: celem jest podjęcie decyzji o najmniejszym ryzyku w świetle posiadanej na dany temat wiedzy.

Definicje bazujące na technicznej i finansowej wykonalności danego projektu, są spotykane dość często i w literaturze i na stronach wielu instytucji3. Metoda prowadzenia takich analiz, bazująca na modelowaniu czyli na analizie systemowej,  wydaje się być jednak najwłaściwszą.

Warto jednak zwrócić uwagę, że wykonalność techniczna a zdolność do sfinansowania to nie to samo…  Studium wykonalności technologicznej dotyczy produktu projektu lub efektu organizacyjnego jakiego oczekujemy. Ocena tego czy pozyskamy finansowanie to nie wykonalność a zdolność do sfinansowania (studium wykonalności finansowo-ekonomicznej3). To są różne analizy.

Wykonalność techniczną opisałem w artykule Studium wykonalności c.d.

Źródła

________________________________
1.
Studium wykonalności (Feasibility study) . POIG. . Published February 17, 2014. Accessed October 24, 2018.
2.
Michał Trocki, Kolegium Zarządzania i Finansów SGH, Kompleksowa ocena projektów. STUDIA I PRACE KOLEGIUM ZARZĄDZANIA I FINANSÓW ZESZYT NAUKOWY 113, Szkoła Główna Handlowa w Warszawie, 2012.
3.
PARP, Zalecenia do studium wykonalności, http://porpw.parp.gov.pl/index/index/2027.
4.
Żeliński J. Utopia czyli model ideału pomaga w projektach. IT-Consulting.pl. https://it-consulting.pl//2013/02/21/utopia-czyli-modelu-idealu-pomaga-w-projektach/. Published March 2, 2015. Accessed October 24, 2018.
Hepburn, B., & Andersen, H. (2021). Scientific Method. In E. N. Zalta (Ed.), The Stanford Encyclopedia of Philosophy (Summer 2021). Metaphysics Research Lab, Stanford University. https://plato.stanford.edu/archives/sum2021/entries/scientific-method/
Ozkaya, M. (2023, April 9). Microservices Architecture. Design Microservices Architecture with Patterns & Principles. https://medium.com/design-microservices-architecture-with-patterns/microservices-architecture-2bec9da7d42a
Weiss, M., & Hari, A. (2004). ICDM - an Integrated Methodology for the Conceptual Design of New Systems. https://www.academia.edu/59514794/ICDM_an_Integrated_Methodology_for_the_Conceptual_Design_of_New_Systems
Włodarska-Dziurzyńska, K. (2012). Pojęcie produktu. Nieuczciwe praktyki rynkowe : ocena regulacji, 141–143. https://ruj.uj.edu.pl/server/api/core/bitstreams/c5d331c9-8945-4f12-9a9b-12eddee0be30/content
Mahesh, B. (2019). Machine Learning Algorithms -A Review. https://doi.org/10.21275/ART20203995
Martin, R. C., & Martin, R. C. (2018). Clean architecture: a craftsman’s guide to software structure and design. Prentice Hall.
Foote, B., & Yoder, J. (1997). Big Ball of Mud. Department of Computer Science University of Illinois at Urbana-Champaign 1304 W. Springfield Urbana, IL 61801 USA. https://www.researchgate.net/publication/2938621_Big_Ball_of_Mud
Alencar, F. (2000). Closing the GAP between organizational requirements and object oriented modeling. Journal of the Brazilian Computer Society. https://www.academia.edu/83364710/Closing_the_GAP_between_organizational_requirements_and_object_oriented_modeling
Rumpe, B. (2007). Model-driven development of complex software: A research roadmap. https://www.academia.edu/16456630/Model_driven_development_of_complex_software_A_research_roadmap
Harmon, P. (2010, December 14). What is a Business Process. BPTrends, 8(21), 6. http://www.bptrends.com/publicationfiles/advisor20101214.pdf
Harmon, P., & Garcia, J. (2020). The States of the Business Process Management Process 2020 (No. 2020). BP Trends Associations. www.bptrends.com
Harmon, P. (2016). The State of Business Process Management 2016. BT Trends. https://www.club-bpm.com/Contenido/Estudios/BPT-Survey-Report.pdf
Nanayakkara, C. (2023, July 7). Microservices Patterns: The Saga Pattern. Cloud Native Daily. https://medium.com/cloud-native-daily/microservices-patterns-part-04-saga-pattern-a7f85d8d4aa3
Gaiardelli, S., Spellini, S., Panato, M., Tadiello, C., Lora, M., Cheng, D. S., & Fummi, F. (2024). Enabling Service-oriented Manufacturing through Architectures, Models and Protocols. IEEE Access, 1–1. https://doi.org/10.1109/ACCESS.2024.3385634
Huang, S.-C. (2006). A semiotic view of information: Semiotics as a foundation of LIS research in information behavior. Proceedings of the American Society for Information Science and Technology, 43(1), 1–17. https://doi.org/10.1002/meet.1450430166
Nuninger, L., Verhagen, P., Libourel, T., Opitz, R., Rodier, X., Laplaige, C., Fruchart, C., Leturcq, S., & Levoguer, N. (2020). Linking Theories, Past Practices, and Archaeological Remains of Movement through Ontological Reasoning. Information, 11, 338. https://doi.org/10.3390/info11060338
Machado, I. (2015). Graphic argumentation: diagrammatic modeling in the communication of science. Communicating and Evaluating Science. Covilhã: Labcom, 177–202. https://www.researchgate.net/profile/Catarina_Gracio_De_Moura/publication/324314608_Communicating_and_Evaluating_Science/links/5c6485c8299bf1d14cc4bc1c/Communicating-and-Evaluating-Science.pdf#page=181
Machado, I. (n.d.). Graphic argumentation: diagrammatic modeling in the. Communication and Evaluating Science, 177–202. Retrieved April 11, 2024, from https://www.academia.edu/download/92934020/Irene_Machado.pdf
Jerzy Zajadło. (2019). Banał formuły “dura lex sed lex.” Banał formuły “dura lex sed lex,” R. 64, nr 5, 5–12. https://palestra.pl/pl/czasopismo/wydanie/5-2019/artykul/banal-formuly-dura-lex-sed-lex
Korycka-Zirk, M., & Dobrzeniecki, K. (2018). Logika dla prawników: kompendium i zadania (Wydanie II rozszerzone). Towarzystwo Naukowe Organizacji i Kierownictwa “Dom Organizatora.”
Lewandowski, S., & Malinowski, A. (Eds.). (2002). Logika dla prawników. Wydaw. Prawnicze “LexisNexis.”
Lewandowski, S., Machińska, H., Malinowski, A., Petzel, J., & Pełka, M. (Eds.). (2022). Logika dla prawników (Wydanie 13). Wolters Kluwer.
Lewandowski, S., Malinowski, A., & Petzel, J. (Eds.). (2021). Logika dla prawników: słownik encyklopedyczny (3. wydanie zaktualizowane i rozszerzone). Wolters Kluwer.
Friedman, J. (1997). What’s wrong with Libertarianism. Critical Review, 11(3), 407–467. https://doi.org/10.1080/08913819708443469
Singla, A., Nathan, V. T., & Vageesh, S. (2016). Model Based Self‐Learning System Engineering Approach. INCOSE International Symposium, 26(s1), 219–233. https://doi.org/10.1002/j.2334-5837.2016.00327.x
Sarnowski, J. (2022). Podatki w krajach nordyckich a gospodarka i dobrobyt. Doradztwo Podatkowe - Biuletyn Instytutu Studiów Podatkowych, 5(309), 4–14. https://doi.org/10.5604/01.3001.0015.8617
Ackoff, R. L., Magidson, J., Addison, H. J., & Ehrlich, A. (2007). Projektowanie ideału: kształtowanie przyszłości organizacji. Wyższa Szkoła Przedsiębiorczości i Zarządzania im. Leona Koźmińskiego : Wydawnictwa Akademickie i Profesjonalne. https://repozytorium.kozminski.edu.pl/pl/pub/3442
Babalola, V. (2016). Public Private Partnership: Imperative in Educational Planning and Management for Human Security in Nigerian Schools. 6.
Keet, C. M., & Fillottrani, P. R. (2015). An Analysis and Characterisation of Publicly Available Conceptual Models. In P. Johannesson, M. L. Lee, S. W. Liddle, A. L. Opdahl, & Ó. Pastor López (Eds.), Conceptual Modeling (Vol. 9381, pp. 585–593). Springer International Publishing. https://doi.org/10.1007/978-3-319-25264-3_45
Busboom, A. (2024). Automated generation of OPC UA information models — A review and outlook. Journal of Industrial Information Integration, 100602. https://doi.org/10.1016/j.jii.2024.100602
Michalak. (n.d.). Ustawa o prawie autorskim i prawach pokrewnych. Komentarz. Wolters Kluwer. Retrieved March 23, 2024, from https://www.ksiegarnia.beck.pl/media/product_custom_files/1/8/18361-ustawa-o-prawie-autorskim-i-prawach-pokrewnych-komentarz-arkadiusz-michalak-fragment_1.pdf
Brambilla, M., Cabot, J., & Wimmer, M. (2012). Model-driven software engineering in practice. Morgan & Claypool.
Boisot, M., & Canals, A. (2004). Data, information and knowledge: have we got it right? Journal of Evolutionary Economics, 14(1), 43–67. https://doi.org/10.1007/s00191-003-0181-9
Chen, M., Ebert, D., Hagen, H., Laramee, R. S., Van Liere, R., Ma, K.-L., Ribarsky, W., Scheuermann, G., & Silver, D. (2008). Data, information, and knowledge in visualization. IEEE Computer Graphics and Applications, 29(1), 12–19. https://ieeexplore.ieee.org/abstract/document/4736452/
Floridi, L. (2005). Is Semantic Information Meaningful Data? Philosophy and Phenomenological Research, 70(2), 351–370. https://doi.org/10.1111/j.1933-1592.2005.tb00531.x
Zins, C. (2007). Conceptual approaches for defining data, information, and knowledge. Journal of the American Society for Information Science and Technology, 58(4), 479–493. https://doi.org/10.1002/asi.20508
Foehr, M., Vollmar, J., Calà, A., Leitão, P., Karnouskos, S., & Colombo, A. (2017). Engineering of Next Generation Cyber-Physical Automation System Architectures. In Multi-Disciplinary Engineering for Cyber-Physical Production Systems: Data Models and Software Solutions for Handling Complex Engineering Projects (pp. 185–206). https://doi.org/10.1007/978-3-319-56345-9_8
(N.d.).
(N.d.).
Therefore, use a Repository, the purpose of which is to encapsulate all the logic needed to obtain object references. The domain objects won’t have to deal with the infrastructure to get the needed references to other objects of the domain. They will just get them from the Repository and the model is regaining its clarity and focus. (n.d.).
Therefore, a new concept is necessary to be introduced, one that help to encapsulate the process of complex object creation. This is called Factory. Factories are used to encapsulate the knowledge necessary for object creation, and they are especially useful to create Aggregates. When the root of the Aggregate is created, all the objects contained by the Aggregate are created along with it, and all the invariants are enforced. (n.d.).
Therefore, use Aggregates. An Aggregate is a group of associated objects which are considered as one unit with regard to data changes. The Aggregate is demarcated by a boundary which separates the objects inside from those outside. Each Aggregate has one root. The root is an Entity, and it is the only object accessible from outside. The root can hold references to any of the aggregate objects, and the other objects can hold references to each other, but an outside object can hold references only to the root object. If there are other Entities inside the boundary, the identity of those entities is local, making sense only inside the aggregate. (n.d.).
A Service should not replace the operation which normally belongs on domain objects. We should not create a Service for every operation needed. But when such an operation stands out as an important concept in the domain, a Service should be created for it. There are three characteristics of a Service: 1. The operation performed by the Service refers to a domain concept which does not naturally belong to an Entity or Value Object. 2. The operation performed refers to other objects in the domain. 3. The operation is stateless. (n.d.).
Entities are important objects of a domain model, and they should be considered from the beginning of the modeling process. It is also important to determine if an object needs to be an entity or not, which is discussed in the next pattern. (n.d.).
(N.d.).
(N.d.).
However, when domain-related code is mixed with the other layers, it becomes extremely difficult to see and think about. Superficial changes to the UI can actually change business logic. To change a business rule may require meticulous tracing of UI code, database code, or other program elements. Implementing coherent, model-driven objects becomes impractical. (n.d.).
In an object-oriented program, UI, database, and other support code often gets written directly into the business objects. Additional business logic is embedded in the behavior of UI widgets and database scripts. This some times happens because it is the easiest way to make things work quickly. (n.d.).
Patrz architektura heksagonalna. (n.d.).

Jarosław Żeliński

Jarosław Żeliński: autor, badacz i praktyk analizy systemowej organizacji: Od roku 1991 roku, nieprzerwanie, realizuje projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzi samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzi wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie.) Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów. Prawa autorskie: Zgodnie z art. 25 ust. 1 pkt. 1) lit. b) ustawy o prawie autorskim i prawach pokrewnych zastrzegam, że dalsze rozpowszechnianie artykułów publikowanych w niniejszym serwisie jest zabronione bez indywidualnej zgody autora (patrz Polityki Strony).

Ten post ma 6 komentarzy

  1. Katarzyna

    a może należałoby rozróżnić produkt, który odpowiada na pytanie “CZY należy coś robić” od produktu “JAK należy coś robić” przygotowując na potrzeby pierwszego pytania Studium Możliwości, a drugiego – Studium Wykonalności?

    1. Jaroslaw Zelinski

      Jak najbardziej, pierwsze pytanie zadaje się na etapie opracowanie opracowywania strategii i taktyki (to zadanie sponsora projektu) … Studium wykonalności to kolejny etap: czy to co chcemy zrobić jest w ogóle wykonalne. 😉

  2. jacek2v

    Moim zdaniem studium to dokument analityczny, który ma być podstawą podejmowania decyzji. Powinien zawierać wiele opcji realizacji i nie powinien zawierać “wszystkich szczegółów operacyjnych” – co sugeruje definicja z Portalu Funduszy Europejskich. Obowiązkowy jest opis problemu, który chcemy rozwiązać i cele jakie chcemy osiągnąć. Szczegółowy opis obecnej sytuacji jest wręcz niewskazany – dokument ten powinien być w miarę zwięzły i ma być kwintesencją, jeśli ma być podstawą decyzji. Takie studium nie jest pracą dla sprawnego “pisarza” specyfikacji, ale dla kompetentnego i doświadczonego fachowca z umiejętnościami analitycznego myślenia w makro i mikro skali, intuicją oraz sprawnie korzystającego z różnych źródeł zewnętrznych (eksperci, badania, raporty itp.)

  3. Gosia

    a jak wyglada sprawa takiego działania: Wykonawca zobowiązany będzie do aktualizacji studium zgodnie z wymaganiami UE w terminie 3 dni od uzyskania informacji od Zamawiającego.
    na czym polega ta aktualizacja? Bo studium to opis itd, ale AKTUALIZACJA?

    1. Jaroslaw Zelinski

      Aktualizacja oznacza, że było dobre ale z upływem pewnego czasu “coś” się zmieniło i Studium wymaga “aktualizacji”… Jednak moim zdaniem jest to pewne nadużycie gdyż opracowania takie są wykonywane w określonych warunkach jakimi są stan wiedzy na dzień opracowania. Jeżeli te warunki się zmieniają to studium należy powtórzyć, pojęcie “aktualizacja” jest tu raczej nie na miejscu. Jeżeli zmieniły się warunki należy powtórzyć analizę, bo “aktualizacja” analizy po zmianie “warunków” to przegląd i powtórne jej opracowanie. Owszem pracochłonność pewnie jest mniejsza ale jednak. Typowy przykład to zarządzanie zmianą w projekcie. Ktoś zgłasza chęć wprowadzenia zmiany, w efekcie musi nastąpić ocena jak ta zmiana wpłynie na cały projekt i na tej podstawie ma miejsce przeprojektowanie, zwaną potocznie “aktualizacją”.

      Tak więc zapis “Wykonawca zobowiązany będzie do aktualizacji studium zgodnie z wymaganiami UE w terminie 3 dni od uzyskania informacji od Zamawiającego.” wymaga określenia kontekstu: co jest przyczyną konieczności dokonania tej aktualizacji.

Dodaj komentarz

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.