Cosa significa legalmente l'obiettivo di gestione e l'obiettivo numerico in un progetto di sviluppo di sistema?

I progetti di sviluppo di sistemi sono spesso strettamente legati a miglioramenti significativi nelle operazioni aziendali e sul posto di lavoro. In questo contesto, potrebbe essere richiesto un impegno per risolvere i problemi di gestione dell’azienda lato utente o per raggiungere obiettivi numerici. Tuttavia, l’impegno per tali obiettivi di gestione è davvero un obbligo legale? Il problema diventa quale sia il significato legale degli obiettivi numerici e di gestione. In questo articolo, discuteremo i problemi legali associati ai vari “obiettivi” e “scopi” nel sviluppo di sistemi.

Perché gli obiettivi e le finalità dello sviluppo di un sistema diventano spesso motivo di conflitto?

Perché si trova tra l’obbligo di cooperazione dell’utente e la discrezionalità del fornitore

Se si considera dal punto di vista delle transazioni commerciali, ci sono alcuni aspetti caratteristici nei progetti di sviluppo di sistemi. Uno di questi è che lo sviluppo di un sistema da parte di un fornitore non può essere realizzato solo dal fornitore, ma richiede la cooperazione dell’utente. Questo obbligo è noto nella giurisprudenza come “obbligo di cooperazione”. In particolare, si richiede la cooperazione dell’utente nelle fasi di ① definizione dei requisiti ② progettazione di base ③ accettazione dei risultati.

https://monolith.law/corporate/user-obligatory-cooporation[ja]

Un altro aspetto è che al fornitore è generalmente richiesto di esercitare una grande discrezionalità nel suo lavoro. C’è un termine legale chiamato “obbligo di gestione del progetto” che riassume ciò che il fornitore dovrebbe fare in un progetto di sviluppo di sistema. Questo è spiegato in dettaglio nel seguente articolo.

https://monolith.law/corporate/project-management-duties[ja]

Riassumendo quanto sopra, possiamo sottolineare due punti importanti:

• L’utente è richiesto nella pratica di fornire le informazioni necessarie al fornitore e di cooperare con il lavoro di sviluppo del fornitore.
• Al fornitore è richiesto nella pratica di comprendere gli obiettivi e le finalità del progetto per l’utente e di intraprendere azioni in linea con questi.

A causa di queste due circostanze, diventa un problema fino a che punto l’obiettivo di gestione e l’obiettivo numerico, che sono stati spiegati in anticipo dall’utente, possono diventare un obbligo legale per il fornitore. In altre parole, c’è un aspetto in cui è un obbligo dell’utente riassumere ciò che il fornitore dovrebbe fare (non qualcosa di vago come un obiettivo) in specifiche e presentarlo, ma c’è anche un aspetto in cui il fornitore ha l’obbligo di fornire ciò che l’utente richiede essenzialmente come esperto (non solo facendo ciò che gli è stato detto di fare). Questo conflitto tra le due parti con posizioni contrastanti è una caratteristica dei conflitti riguardanti gli “obiettivi” e le “finalità” dello sviluppo di un sistema. Inoltre, dal punto di vista legale, presentare linee guida per la risoluzione dei conflitti che siano equi per entrambe le parti è una sfida pratica.

Scenari concreti in cui gli obiettivi dell’utente influenzano il progetto

I progetti di sviluppo di sistemi sono spesso legati a misure di miglioramento ed efficienza di grandi operazioni aziendali o sul posto di lavoro, e spesso si svolgono colloqui sulla gestione e gli obiettivi di gestione anche nelle fasi di pianificazione e proposta. In questo contesto, si possono considerare scambi riguardanti il rapporto costo-efficacia dello sviluppo di un sistema e vari obiettivi numerici.

• Riduzione dei costi del personale dovuta all’automazione
• Aumento delle vendite o dei profitti
• Riduzione del tempo di lavoro

Ad esempio, se gli elementi sopra menzionati sono l’obiettivo finale del progetto, si può immaginare che il fornitore spieghi in anticipo l’effetto dell’investimento nello sviluppo del sistema da una posizione simile a quella di un consulente e conduca le vendite.

Casi giudiziari in cui gli obiettivi di gestione proposti dall’utente sono diventati un problema

Tuttavia, il fornitore è, in ultima analisi, un esperto di sviluppo di sistemi. Se tutte le responsabilità ricadono sugli obiettivi di gestione dell’utente, potrebbe diventare una situazione troppo dura.

Il caso in cui l’obiettivo era migliorare la velocità delle operazioni

In relazione a questo, nel caso citato nella sentenza qui sotto, il progetto di sviluppo del sistema aveva obiettivi e scopi scritti nel piano d’azione creato all’inizio del progetto. Tuttavia, una volta completato il sistema e avviato il suo funzionamento, non è stato possibile raggiungere questi obiettivi e scopi, e la situazione è degenerata in un conflitto. Il piano iniziale prevedeva di realizzare le seguenti condizioni una volta che il sistema fosse stato completato e messo in uso:

• Ridurre del 50% il tempo di inserimento manuale
• Completare le operazioni amministrative utilizzando il sistema IT entro un periodo di tempo specificato

L’utente ha cercato di perseguire il fornitore per responsabilità per inadempimento contrattuale e responsabilità per difetti a causa dell’incapacità di realizzare questi risultati. Tuttavia, il tribunale non ha accettato questo argomento (le parti sottolineate e in grassetto sono state aggiunte dall’autore).

E quindi, (omissis) secondo l’intero argomento del dibattito, ① l’obiettivo di questo caso è “migliorare l’efficienza delle operazioni”, “costruire una base per il CRM”, “gestire in modo visibile”, ecc., che sono astratti, e i target, come “aumentare i punti di contatto con i clienti”, “ridistribuire il lavoro del personale amministrativo per il controllo interno e il supporto alle vendite”, “rendere le previsioni di vendita più accurate”, “controllare gli sconti eccessivi sulle vendite”, ecc., sono principalmente astratti, e “ridurre il tempo di inserimento del 50%”, “ridurre il tempo di stima del 50%”, “essere in grado di fare la divulgazione legale entro il periodo legale”, ecc., sono target che dipendono dalla gestione e dal modo di fare affari dell’imputato dopo l’introduzione di SBO, e non sono di natura tale che una società di sviluppo di sistemi che supporta l’introduzione di software di pacchetto, come il querelante, possa assumersi la responsabilità di raggiungerli, ② nei verbali delle riunioni dopo il kickoff del progetto in questione, non c’è alcuna menzione di aver discusso concretamente il raggiungimento dell’obiettivo e del target, ③ nel piano del progetto in questione, espressioni come “diventare una società quotata”, che non hanno di per sé la natura di un contratto, sono state utilizzate, (omissis) considerando queste circostanze, si può ritenere che il querelante abbia creato la descrizione dell’obiettivo del progetto in questione sulla base delle spiegazioni dell’imputato, al fine di evitare che il progetto in questione fallisca, per ottenere una comprensione comune dell’obiettivo e dei risultati del progetto in questione, e non si può ritenere che l’imputato abbia incaricato il querelante di sviluppare un sistema per raggiungere l’obiettivo in questione, (omissis) quindi, non si può ritenere che il querelante abbia assunto l’incarico di sviluppare un sistema per raggiungere l’obiettivo in questione dall’imputato, (omissis) quindi, non ci sono ragioni per le affermazioni di responsabilità per inadempimento contrattuale e responsabilità per difetti.

Giudizio del Tribunale di Tokyo, 28 dicembre 2010 (2010)

Il significato legale degli obiettivi di gestione e degli obiettivi numerici che si possono dedurre dai casi giudiziari

Come menzionato in questa sentenza, se gli obiettivi dello sviluppo del sistema o gli obiettivi quantificati numericamente possono essere raggiunti o meno dipende normalmente da vari fattori, come gli sforzi di gestione dell’utente che utilizza il sistema. Pertanto, dovremmo considerare che la soglia per attribuire la responsabilità al fornitore è molto alta. In primo luogo, se la responsabilità del fornitore per inadempimento contrattuale o responsabilità per difetti fosse riconosciuta, significherebbe che il raggiungimento degli “obiettivi” o degli “obiettivi” era parte del contenuto del contratto. Tuttavia, nel presente caso, gli “obiettivi” e gli “obiettivi” sono stati valutati legalmente come segue:

• Per quanto riguarda quelli astratti e vaghi, è difficile considerarli parte del contenuto del contratto perché non si adattano alla natura di un obbligo legale.
• Per quanto riguarda quelli che richiedono gli sforzi di auto-aiuto dell’utente, in particolare dal lato della gestione, è inappropriato attribuirli al fornitore, poiché sono fuori dal controllo del fornitore, e quindi è difficile considerarli parte dell’obbligo contrattuale.

Questo è il tipo di valutazione che ha ricevuto legalmente.

Cosa si può dedurre ulteriormente da questa sentenza

Ci sono anche alcuni contenuti interessanti in questa sentenza.

• Il fatto che il tribunale consideri anche la possibilità che la condivisione degli “obiettivi” e degli “obiettivi” del progetto di sviluppo del sistema sia solo uno sforzo di comunicazione per ottenere una “comprensione comune” tra l’utente e il fornitore.
• Il fatto che si riferisca anche ai verbali delle riunioni quando considera quanto questi “obiettivi” e “obiettivi” siano elementi essenziali in tutto il progetto.

Per quanto riguarda i problemi legali associati ai progetti di sviluppo di sistemi, abbiamo discusso dell’importanza della gestione dei documenti e dei verbali delle riunioni nel seguente articolo.

https://monolith.law/corporate/the-minutes-in-system-development[ja]

Considerazioni legali riguardo agli obiettivi di gestione e agli obiettivi numerici

Tuttavia, riguardo a questi problemi legali legati a “scopi” e “obiettivi”, dovremmo tenere in considerazione anche le seguenti note aggiuntive.

La questione cambia a seconda se la consulenza è a pagamento o gratuita

Se, oltre al progetto di sviluppo del sistema, avete stipulato un contratto di consulenza a pagamento, la situazione potrebbe cambiare notevolmente. Se, senza considerare quante risorse di gestione l’utente ha, avete stabilito un piano di esecuzione con scarse possibilità di realizzazione, potreste essere perseguiti per inadempimento del contratto di consulenza a pagamento.

Il difetto del prodotto finale, l’incongruenza delle funzioni e delle specifiche sono problemi separati

Inoltre, se ci sono difetti nel progetto di “sviluppo” stesso, cioè se si riscontrano problemi o bug nel prodotto finale, è necessario capire che questi sono problemi separati. In questo caso, non si parla di “scopi” o “obiettivi” di gestione, ma principalmente della coerenza tra il prodotto finale e le funzioni e le specifiche richieste. Ad esempio, abbiamo spiegato le misure che l’utente dovrebbe prendere se si scoprono difetti nel sistema dopo il fatto nel seguente articolo.

https://monolith.law/corporate/system-flaw-measure-after-acceptance[ja]

Un altro argomento correlato è che ci sono cose che si ritiene che il fornitore debba implementare a sua discrezione, anche se non sono incluse nelle specifiche. Questo è spiegato in dettaglio nel seguente articolo.

https://monolith.law/corporate/system-development-specs-funct[ja]ion

In entrambi i casi, dovremmo capire che sono cose simili ma diverse dai conflitti riguardanti “scopi” e “obiettivi”.

È richiesta una comprensione fondamentale di temi come responsabilità e contratti

Abbiamo discusso le questioni legali relative agli “obiettivi” e agli “scopi” dello sviluppo di sistemi. In controversie su tali questioni, i tribunali spesso considerano gli sforzi per allineare gli utenti e i fornitori come parte degli sforzi di comunicazione, e si ritiene che capiscano pienamente che spesso si condividono reciprocamente. Tuttavia, anche se la validità della conclusione stessa può essere pienamente compresa attraverso il senso pratico come professionista, nel processo per arrivarci, viene richiesta una comprensione fondamentale di cose come “responsabilità” e “contratti”. Discutiamo di questi punti nell’articolo seguente.

https://monolith.law/corporate/responsibility-system-development[ja]

È importante comprendere in modo più essenziale che la responsabilità legale è diversa da una responsabilità morale vaga, e che l’accordo chiaro delle “intenzioni” di entrambe le parti è ciò che genera la responsabilità contrattuale.