Digitalisierung der Steuerfunktion - IT-Recht nicht vergessen!

Wahr­schein­lich sollte man sich nicht nur um das rich­tige Tool, son­dern frühzei­tig auch um die ent­spre­chende ver­trag­li­che Aus­ge­stal­tung Ge­dan­ken ma­chen. Was gilt es ge­ne­rell zu be­ach­ten?

Lau­rent Meis­ter: Die An­ge­bote der An­bie­ter und gute Ver­triebler ver­lei­ten Un­ter­neh­men häufig dazu, da­von aus­zu­ge­hen, dass das Tool für die ei­ge­nen Pro­zesse per­fekt passt und schnell im­ple­men­tiert wer­den kann. Doch die Tücke steckt häufig im De­tail. Des­halb sollte die Im­ple­men­tie­rung von Tools recht­lich be­glei­tet wer­den. Kei­nes­falls soll­ten die Verträge der An­bie­ter ohne wei­tere ju­ris­ti­sche Prüfung ein­fach durch­ge­wun­ken wer­den. Da­bei gilt es natürlich auch, die un­ter­schied­li­chen Kon­stel­la­tio­nen zu be­ach­ten. Wird der Soft­ware­an­bie­ter da­mit be­auf­tragt, ein ei­ge­nes Tool für das Un­ter­neh­men zu ent­wi­ckeln bzw. Soft­ware auf Un­ter­neh­mens­bedürf­nisse an­zu­pas­sen oder wird le­dig­lich be­ste­hende Soft­ware ei­nes Dritt­an­bie­ters ein­ge­kauft? Ge­rade bei Ent­wick­lungs- und Im­ple­men­tie­rungs­pro­jek­ten können die avi­sierte Dauer und die Kos­ten schnell aus dem Ru­der lau­fen. Hier ist es wich­tig, wirk­same Me­cha­nis­men im Ver­trag vor­zu­se­hen, die sol­che Ri­si­ken ab­fe­dern. Auch sollte seit Einführung der DS­GVO die Da­ten­schutz­kon­for­mität der Tools be­ach­tet wer­den.

Wie sollte man bei der Pla­nung des Ein­sat­zes ei­nes be­stimm­ten Tools vor­ge­hen?

Dr. Björn Schal­lock: Zunächst gilt es, den Markt der mögli­chen An­bie­ter zu son­die­ren; oft gibt es auch bran­chen­spe­zi­fi­sche Lösun­gen. Diese können vor­zugswürdig sein, weil da­mit der Im­ple­men­tie­rungs­auf­wand ver­rin­gert wird. Das schont per­so­nelle und nicht zu­letzt auch fi­nan­zi­elle Res­sour­cen des Un­ter­neh­mens.

Cloud­ba­sierte Lösun­gen (und da­mit ge­mie­tete Soft­ware) ha­ben den Vor­teil der ge­rin­ge­ren, über­wie­gend lau­fen­den Kos­ten, während bei ei­ner ge­kauf­ten Li­zenz höhere Ein­mal­kos­ten für die An­schaf­fung an­fal­len.

Ne­ben dem funk­tio­na­len Um­fang und der Kom­pa­ti­bi­lität des Tools mit ei­ge­nen Sys­te­men und Pro­zes­sen sollte auch die Er­fah­rung des An­bie­ters so­wie das ein­ge­setzte Per­so­nal berück­sich­tigt wer­den. Vor­han­dene Bran­chen­er­fah­rung kann bei der Kom­mu­ni­ka­tion und Um­set­zung des Pro­jekts hilf­reich sein.

Wie läuft dann die An­schaf­fung des „aus­er­ko­re­nen“ Tools?

Lau­rent Meis­ter: Be­vor das Pro­jekt­team an die Ar­beit geht, sollte un­be­dingt der ge­plante Leis­tungs­um­fang er­ar­bei­tet, be­preist und für den Ver­trag fest­ge­hal­ten wer­den. Dies ge­schieht oft in Work­shops mit dem An­bie­ter, die man auch ge­son­dert vorab be­auf­tra­gen kann, ohne sich schon fest­zu­le­gen. Manch­mal ist das auch ganz prak­ti­sch, um den An­bie­ter und seine Ar­beits­weise erst ein­mal ken­nen­zu­ler­nen und zu prüfen. So­dann sollte der endgültige Ver­trag mit recht­li­cher Un­terstützung ver­han­delt und ab­ge­schlos­sen wer­den.

Dies gilt auch - oder viel­leicht so­gar ganz be­son­ders -, wenn man sich mit dem An­bie­ter auf eine agile Pro­jek­tum­set­zung ei­nigt. Häufig will man mit ei­ner agi­len Um­set­zung „lästige“ Vor­fra­gen und De­tail­pla­nun­gen um­ge­hen und lie­ber di­rekt in die Um­set­zung star­ten. Doch auch bei der agi­len Um­set­zung sind klare Vor­ga­ben, was die Me­tho­dik und Kon­fliktlösung an­geht, wich­tig. Nur so können häufig schnell auf­tre­tende Miss­stim­mun­gen be­sei­tigt wer­den. Dies gilt insb., wenn es sich um das er­ste agile Pro­jekt auf Sei­ten des Kun­den han­delt.

Tool ist nicht gleich Tool und Soft­wa­re­nut­zung ist nicht gleich Soft­wa­re­nut­zung. Wel­che Ver­trags­ty­pen ha­ben sich in hin­sicht­lich der Nut­zung von Soft­ware am Markt her­aus­ge­bil­det; was ist ty­pi­scher­weise zu re­geln?

Lau­rent Meis­ter: Nicht nur bei der Aus­ge­stal­tung des Im­ple­men­tie­rungs­pro­jekts, son­dern auch bei der Nut­zung der Soft­ware gibt es zahl­rei­che Va­ri­an­ten. Diese wer­den meist über den Um­fang der Nut­zungs­rechte und de­ren Vergütung ge­re­gelt. Bei Soft­ware, die man im ei­ge­nen Un­ter­neh­men in­stal­liert, ha­ben sich ne­ben den klas­si­schen Ein­zel­platz­li­zen­zen, die für einen ein­zel­nen PC li­zen­ziert wer­den, insb. Na­med-User-Li­zen­zen, die für einen kon­kre­ten Nut­zer li­zen­ziert wer­den, und Floa­ting- oder Con­cur­rent-Li­zen­zen eta­bliert. Letz­tere wer­den meist un­ter­neh­mens­weit für eine be­stimmte An­zahl von Nut­zern li­zen­ziert und von wech­seln­den Nut­zern ge­nutzt.

Han­delt es sich um eine Soft­ware, die nicht lo­kal auf dem Ein­zel­com­pu­ter in­stal­liert wird, so ha­ben Cloud- oder „as a Ser­vice“ Dienste die bis­he­ri­gen Out­sour­cing- und Ap­pli­ca­tion-Ser­vice-Pro­vi­ding-Mo­delle wei­test­ge­hend ab­gelöst. Auch spielt im Rah­men der Ent­wick­lung und Nut­zung von Soft­ware das Thema Open Source Soft­ware eine Rolle. Hier wird Soft­ware kos­ten­los un­ter ei­ner „freien“ Li­zenz be­reit­ge­stellt. Doch ge­rade für den kom­mer­zi­el­len Ein­satz ste­cken bei den häufig idea­lis­ti­sch geprägten Li­zen­zen die Tücken im De­tail.

Wel­che der vor­ge­nann­ten Möglich­kei­ten der Soft­wa­re­nut­zung sind ge­genwärtig der Klas­si­ker und Ih­rer Er­fah­rung nach am meis­ten im Ein­satz?

Dr. Björn Schal­lock: Der Trend geht in den letz­ten Jah­ren verstärkt zu SaaS-Mo­del­len, also le­dig­lich ge­mie­te­ter Soft­ware. Da­bei wird zu­meist die ge­samte tech­ni­sche Be­reit­stel­lung „out­ge­sour­ced“ und Soft­ware mit­samt der Kun­den­da­ten z. B. in einem Re­chen­zen­trum bzw. ei­ner Cloud für den Kun­den ge­hos­tet. Da­mit ein­her­ge­hend er­le­ben wir auch den Trend, dass kom­plexe Großsys­teme, die im Rah­men kom­ple­xer Out­sour­cing-Verträge aus­ge­la­gert wer­den, im­mer häufi­ger durch eine Viel­zahl klei­ne­rer Spe­zi­al­an­wen­dun­gen ab­gelöst wer­den. Diese lau­fen meist in der Cloud mit Schnitt­stel­len zu den an­de­ren Sys­te­men. Dies bie­tet den Vor­teil, dass nicht al­les in ei­ner An­wen­dung in­te­griert wer­den muss, son­dern sich die ein­zel­nen Her­stel­ler auf ihre Kern­kom­pe­tenz kon­zen­trie­ren können. Auch lässt sich ein ein­zel­nes klei­nes Tool schnel­ler ablösen als das ein­heit­li­che ERP-Sys­tem zum Bei­spiel.

Ge­setzt dem Fall, der Nut­zer ent­deckt Mängel an der be­schaff­ten Soft­ware, etwa feh­lende Pro­gramm­funk­tio­nen oder feh­lende Leis­tungsfähig­keit - was nun? Wofür haf­tet der Soft­ware­ent­wick­ler?

Dr. Björn Schal­lock: Das hängt wie­derum sehr vom ab­ge­schlos­se­nen Ver­trag ab - und ge­nau des­halb ist die ver­trags­recht­li­che Be­glei­tung ei­nes sol­chen Pro­jek­tes von so großer Wich­tig­keit. Oft ent­hal­ten die von den An­bie­tern ver­wen­de­ten Ver­trags­mus­ter Re­ge­lun­gen zu de­ren Guns­ten, also etwa kurze Verjährungs­fris­ten für Mängel, schwam­mig for­mu­lierte Funk­ti­ons­zu­sa­gen oder Leis­tungs­an­ga­ben und weit­ge­hende Haf­tungs­aus­schlüsse. Das ist dann miss­lich für die Durch­set­zung der ei­ge­nen An­sprüche und kann dazu führen, dass der Kunde am Ende auf dem Scha­den sit­zen bleibt.

In sol­chen Si­tua­tio­nen hört man häufig von Man­dan­ten den ab­ge­dro­sche­nen Satz „Hin­ter­her ist man häufig klüger“. Si­cher kann man mit einem gut for­mu­lier­ten Ver­trag be­stimmte Vor­keh­run­gen für den „worst case“ schaf­fen, doch in den meis­ten Fällen wird man sich am Ende gar nicht darum strei­ten, ob dem Kun­den ein Scha­dens­er­satz­an­spruch in ei­ner be­stimm­ten Höhe zu­steht, son­dern schon viel früher darüber strei­ten, wurde über­haupt et­was ge­lie­fert, was nicht der ver­ein­bar­ten Be­schaf­fen­heit ent­spricht oder sich für den ge­plan­ten Zweck eig­net. In die­sen Fällen sieht man re­gelmäßig, dass es nicht nur dar­auf an­kommt, dass der Ver­trag ge­wisse Re­ge­lun­gen und Me­cha­nis­men enthält, son­dern dass auch in­halt­lich bzw. funk­tio­nal den Par­teien klar ist, was am Ende die Soft­ware kann bzw. können soll. Hier braucht es also am Ende eine Ver­zah­nung aus Ver­trag und Leis­tungs­be­schrei­bung.

Wor­auf sollte bei Verträgen über die Ent­wick­lung von In­di­vi­du­al­soft­ware oder An­pas­sungs­pro­jek­ten von Stan­dard­soft­ware un­be­dingt ge­ach­tet wer­den?

Dr. Björn Schal­lock: Wich­tig und nach un­se­rer Er­fah­rung oft ver­nachlässigt wer­den Re­ge­lun­gen zur Kos­ten­pla­nung und -de­cke­lung zu­guns­ten des Kun­den. Da­durch wer­den Soft­ware­pro­jekte fi­nan­zi­ell viel­fach zu dem berühm­ten Fass ohne Bo­den. Das Ri­siko lässt sich durch gute Be­ra­tung im Vor­feld und durch ver­trag­li­che Maßnah­men al­ler­dings eindämmen.

Auch die verläss­li­che zeit­li­che Um­set­zung ist ein Pro­blem, da An­bie­ter gerne mit un­ver­bind­li­chen Zeitplänen ar­bei­ten möch­ten. Das muss man nicht ak­zep­tie­ren.

Un­ter dem Strich geht es um die Schaf­fung möglichst kla­rer Ver­trags­pflich­ten, was in Be­zug auf die fach­li­che Um­set­zung zu­meist mit mehr Auf­wand zu Be­ginn ver­bun­den ist, wenn alle Be­tei­lig­ten am liebs­ten los­le­gen wol­len, ob­wohl nicht ein­mal die Min­dest­vor­ga­ben klar sind. Da lohnt es sich et­was mehr Zeit in die De­tail­pla­nung zu ste­cken und am Ende mehr Rechts­si­cher­heit zu er­rei­chen.

Es wurde eben ja schon erwähnt, dass heute viel häufi­ger ver­schie­dene Tools ein­ge­setzt wer­den, die über Schnitt­stel­len mit­ein­an­der ver­bun­den sind. Wor­auf ist zu ach­ten, wenn etwa Schnitt­stel­len zu an­de­ren Sys­te­men ein­ge­rich­tet wer­den?

Lau­rent Meis­ter: Schnitt­stel­len sind eine großar­tige Möglich­keit, Da­ten aus einem Sys­tem in einem an­de­ren Sys­tem wei­ter­zu­ver­ar­bei­ten. Je­der An­bie­ter kann sich da­bei auf seine Kern­kom­pe­tenz kon­zen­trie­ren. Die Her­aus­for­de­rung stellt da­bei häufig die Schnitt­stelle dar, insb. wenn sie nicht über ein stan­dar­di­sier­tes Ver­fah­ren oder For­mat er­folgt.

Hier müssen die An­bie­ter sich also zunächst über das Ver­fah­ren und das For­mat des Da­ten­aus­tauschs ei­ni­gen. Das kann in­di­vi­du­ell tatsäch­lich durch ge­mein­same Ent­wick­lun­gen er­fol­gen oder da­durch, dass sich der An­bie­ter des im­por­tie­ren­den Tools auf das Da­ten­for­mat ein­stellt, das das an­dere Pro­gramm oh­ne­hin aus­gibt.

Am Ende ist für den Kun­den im­mer hei­kel, was pas­siert, wenn die Über­tra­gung über die Schnitt­stelle nicht mehr funk­tio­niert. Auf wel­cher Seite ist der Feh­ler auf­ge­tre­ten und ist die Schnitt­stelle zu einem kon­kre­ten Tool über­haupt ver­trag­lich ge­schul­det? Ändert sich etwa das For­mat oder Ver­fah­ren durch ein Up­date des einen Tools, funk­tio­nie­ren beide Tools für sich ge­nom­men feh­ler­frei. Die ein­ge­setz­ten Ver­sio­nen sind nur nicht zu­ein­an­der kom­pa­ti­bel. Hier muss da­her ver­trag­lich mit min­des­tens einem der An­bie­ter ge­re­gelt wer­den, dass er für die not­wen­dige Kom­pa­ti­bi­lität ver­ant­wort­lich ist, und ent­spre­chende Ände­run­gen auch im Rah­men von Up­date-Zy­klen zu berück­sich­ti­gen sind. An­sons­ten kann es auch hier pas­sie­ren, dass der Kunde am Ende im Re­gen steht, weil kei­ner der An­bie­ter die funk­tio­nie­rende An­bin­dung zwi­schen den vom Kun­den ge­nutz­ten Ver­sio­nen schul­det.

Stich­wort Da­ten­schutz. Wie las­sen sich die Nut­zung von Tools und da­ten­schutz­recht­li­che An­for­de­run­gen mit­ein­an­der ver­ein­ba­ren und was ist da­bei recht­lich zu be­ach­ten?

Lau­rent Meis­ter: Spätes­tens seit Einführung der DS­GVO können wir je­dem Un­ter­neh­men emp­feh­len, Da­ten­schutz­fra­gen von Be­ginn an mit zu berück­sich­ti­gen. Das gilt im Übri­gen so­wohl auf An­bie­ter- als auch auf Kun­den­seite. Viele An­bie­ter sind sich noch nicht im Kla­ren darüber, dass Soft­ware mit Einführung der DS­GVO-An­for­de­run­gen an die Si­cher­heit aber auch an die tech­ni­sche Aus­ge­stal­tung, etwa im Be­reich Pri­vacy-by-De­sign bzw. Pri­vacy-by-De­fault, erfüllen muss. Ist dies nicht der Fall, kann sich der Kunde schnell dar­auf be­ru­fen, dass die ge­kaufte Soft­ware man­gel­haft ist, weil sie den ge­setz­li­chen An­for­de­run­gen nicht ent­spricht.

Bei der Nut­zung von Cloud-Lösun­gen oder aus­ge­la­ger­ten Lösun­gen spielt der Da­ten­schutz natürlich eine zen­trale Rolle abhängig da­von, ob die Da­ten da­bei im Aus­land ver­ar­bei­tet wer­den. Hier reicht es häufig schon aus, dass das Sup­port-Per­so­nal des An­bie­ters in den USA oder In­dien sitzt und Zu­griff auf die Da­ten erhält. Auch in die­sen Fällen liegt ein Dritt­staat­trans­fer vor, bei den die ge­stei­ger­ten An­for­de­run­gen nach dem Schrems-II Ur­teil des EuGH ein­ge­hal­ten wer­den müssen. An­dern­falls könn­ten die Auf­sichts­behörden die Nut­zung des Cloud-Diens­tes un­ter­sa­gen und Bußgelder verhängen. Ge­rade mit Blick auf die USA und Eng­land ist die Ent­wick­lung in den kom­men­den Jah­ren si­cher sehr dy­na­mi­sch, so dass man diese An­for­de­run­gen stets im Blick ha­ben und ggf. schnell rea­gie­ren muss. Auch das ein Punkt, den man bei der Aus­wahl des Tools und des An­bie­ters berück­sich­ti­gen sollte.

Hin­weis: Hier geht es zur Stu­die zur Di­gi­ta­li­sie­rung der Steu­er­funk­tion in mit­telständi­schen Un­ter­neh­men.