GAR-EZV Dokument B SOLL-Architektur · 1/107 GAR-EZV Dokument B SOLL-Architektur Klassifizierung * Nicht klassifiziert Status ** Abgenommen Projektname „Geschäftsprinzipien, IT-Architektur

1/107

GAR-EZV Dokument B SOLL-Architektur

Klassifizierung * Nicht klassifiziert

Status ** Abgenommen

Projektname „Geschäftsprinzipien, IT-Architektur und Roadmap EZV“

Projektabkürzung GAR-EZV

Projektnummer 20662

Projektleiter D. Meier

Auftraggeber R. Dietrich

Autoren W.Dänzer; P.Mandelz; D.Meier

Initiale PM; DM

Bearbeitende P.Mandelz; D.Meier; B.Ferrario; S.Käser; P. Dimic

Prüfende Kernteam und fachliche Expertengruppe der Studie GAR-EZV

Genehmigende Projektausschuss der Studie GAR-EZV

Verteiler Kernteam und Mitglieder PA

Doc_ID GAR-EZV_Dokument B SOLL-Architektur_v.1.0.docx

Kurzbeschreibung

Die heutige heterogene IT-Landschaft der EZV soll analysiert werden und

anhand von Geschäftsprinzipien zu einer SOLL-Architektur geführt wer-

den.

Als Ausgangslage dient die Ist-Analyse der Architektur, welche den Hand-

lungsbedarf aufzeigt. Anhand der definierten Geschäftsprinzipien kann

eine SOLL-Architektur abgeleitet werden. Dieser Zustand wird geplant

und gesteuert über die Roadmap, welche sich an die jährlichen Transiti-

onsarchitekturen orientiert.

Die aus dem Projekt GAR-EZV hervorgehende Roadmap befähigt die

EZV, durch jährliche Revalidierung der Ist-Situation und den Transitions-

architekturen, eine strategische IKT Planung zu führen.

* Nicht klassifiziert, Intern, Vertraulich

** In Arbeit, In Prüfung, Abgeschlossen

Projektname: GAR-EZV

Ergebnisname: Geschäftsprinzipien & SOLL-Architektur

2/107

Begriffe und Abkürzungen

Begriff / Abkürzung Bedeutung

ADM Architecture Development Method (Bestandteil von TOGAF)

AEO Zugelassener Wirtschaftsbeteiligter (“Authorized Economic Operator”; Unter-

nehmen mit bestimmten Privilegien)

Aktivität Prozessschritt (Synonym)

Architektur Fundamentaler Aufbau eines Systems, bestehend aus seinen einzelnen Kom-

ponenten, deren Beziehungen zueinander und zur Umwelt. Beinhaltet Prinzi-

pien, die Design und Weiterentwicklung steuern.

B2B

Die Abkürzung B2B steht für „business-to-business“, also der Geschäftsbezie-

hung zwischen mindestens zwei Unternehmen resp. Partnern. Im Zusammen-

hang der SOLL-Architektur ist die technische Komponente gemeint, welche

eine solche „business-to-business“-Beziehung ermöglicht.

BHB Betriebshandbuch

BI

Business Intelligence - Gewinnung von Erkenntnissen, die in Hinsicht auf die

Unternehmensziele bessere operative oder strategische Entscheidungen er-

möglichen

BIT Bundesamt für Informatik und Telekommunikation

DSG Datenschutzgesetz

DoS Denial of Service, Angriff auf die Verfügbarkeit

EAV Eidgenössische Alkoholverwaltung

EFD Eidgenössisches Finanzdepartement

EJPD Eidgenössisches Justiz- und Polizeidepartement

ESB

Enterprise Service Bus – Ansatz für eine grundlegende Integrationsarchitek-

tur, die serviceorientiert ist und der Kommunikation zwischen unterschiedli-

chen Backend-Systemen und Geschäftsdiensten dient.

EU Europäische Union

EZV Eidgenössische Zollverwaltung

Funktion

Konzeptioneller Baustein einer Architektur, der verwendet wird, um Beziehun-

gen zwischen Architekturebenen abzubilden. Eine (Geschäfts-) Funktion dient

der Verknüpfung von Aktivitäten auf Prozessebene mit Funktionalitäten von

Applikationen. In Anlehnung an die ReFa GS EFD wurde die Bezeichnung von

Geschäftsfähigkeit zu Geschäftsfunktion geändert.

GNC Globally Networked Customs (Architekturstandard der WZO für den Informati-

onsaustausch zwischen Zollbehörden)

GS Generalsekretariat

IAM Identity- und Access-Management

IKT Informations- und Kommunikationstechnik



3/107


ISB Informatiksteuerungsorgan des Bundes

ISDS-Konzept Informations- und Datenschutzgesetz

Kunde

Natürliche oder juristische Person, die gegenüber der EZV Pflichten, Rechte

oder andere Kundenbedürfnisse hat. Als gleichwertiges Synonym für Kunde

gelten auch die Begriffe Zollbeteiligter, Abgabepflichtiger und Rückerstat-

tungsberechtigter.

Beispiel Pflichten: zuführungspflichtig, anmeldepflichtig, abgabenpflichtig,

steuerpflichtig, ausweispflichtig, dokumentenpflichtig

Beispiel Rechte: steuerbegünstigungsberechtigt, rückerstattungsberechtigt,

eintragungsberechtigt

Leistungsauftrag Unter Leistungsauftrag werden Aufgaben ex Leistungsauftrag und anderen

Aufgaben der EZV verstanden.

LIMS Laborinformationssystem

LSVA Leistungsabhängige Schwerverkehrsabgabe

NZE Nichtzollrechtlicher Erlass

OZD Oberzolldirektion

Partner

Als Partner sind in diesem Dokument Beteiligte an einer Aufgabe, welche die

EZV unterstützen oder durch die EZV unterstützt werden.

Beispiel: Bundesämter, Zollbehörden anderer Länder

PKI Bund Public-Key-Infrastruktur des Bundes

PSP Personensicherheitsprüfung

Schuban Schutzbedarfsanalyse

SECO Staatssekretariat für Wirtschaft («Secrétariat d‘Etat à l‘économie»)

SIP Strategische Informatikplanung

SOA Serviceorientierte Architektur (Architekturstil)

SUC System Use Case

Swiss-Gov-CA Oberste Zertifizierungsstelle für elektronische Zertifikate der BV

TOGAF The Open Group Architecture Framework

User

Unter dem Begriff User werden Anwender oder Benutzer aller möglichen Ap-

plikationen und Services der EZV verstanden. Darunter gehören sowohl Kun-

den, Partner als auch Mitarbeitende.

VDI Virtual Desktop Infrastruktur

VSP Verbrauchssteuerplattform (Sistiertes Projekt)

WAF Webapplication Firewall, Infrastruktur zur Filterung von Webinhalten

WIsB Weisungen des Bundesrates über die IKT-Sicherheit in der BV



4/107


ZAZ Zentralisiertes Abrechnungsverfahren der Zollverwaltung

ZE Zugelassener Empfänger (gemäss [ZollV], Art. 101)

ZV Zugelassener Versender (gemäss [ZollV], Art. 100)

Referenzen

Erkennungszeichen Titel, Quelle

[BinfV]

Verordnung über die Informatik und Telekommunikation in der Bundesverwal-

tung, siehe

http://www.admin.ch/opc/de/classified-compilation/20081009/index.html

[BIT A-Prinzipien]

IT-Architektur-Prinzipien – Version 1.2

http://intranet.bit.admin.ch/dokumentation/02687/02690/02975/in-

dex.html?lang=de

[BuA-AP] Bundesarchitektur – Preliminary Phase – Architekturprinzipien

[DSG] Bundesgesetz über den Datenschutz, siehe


[EGOVCH01] E-Government-Strategie Schweiz, siehe

http://www.egovernment.ch/egov/00833/00834/index.html?lang=de

[FrachtTA] Dok_Technologiearchitektur_Redesign Fracht EZV_V3.0_final

[GAR-PAUF] Projektinitialisierungsauftrag GAR-EZV

[GAR-ISTARCH] Dokument A – IST-Architektur GAR-EZV

[GAR-UP] Dokument C – Umsetzungsplanung GAR-EZV

[GO-OZD] Geschäftsordnung der Oberzolldirektion

[GO-OZD-A2] Geschäftsordnung der Hauptabteilung Betrieb (GO A 2)

[IKT-PP-EZV] Positionspapier IKT der EZV

[IKT-Sich-LB-Bund] IKT-Sicherheitsleitbild der Bundesverwaltung, siehe

http://www.isb.admin.ch/themen/sicherheit/00150/01215/index.html?lang=de

[IKT-Strat-Bund] IKT-Strategie des Bundes 2012–2015, siehe

http://www.isb.admin.ch/themen/strategien/00070/index.html?lang=de&

[IRB-TOGAF]

“P030 – The Open Group Architecture Framework (TOGAF) als Unterneh-

mensarchitektur Methode für die Bundesverwaltung“, siehe

http://www.isb.admin.ch/themen/standards/alle/03264/?lang=de

[ISB-AE-TOGAF] Architekturentwicklung mit TOGAF – Leitfaden des ISB für Unternehmensar-

chitekten in der öffentlichen Verwaltung

[ISB-SOA-

GLOSSAR]

Das SOA Glossar dient als Ergänzung zu den diversen Dokumenten, die sich

direkt oder indirekt mit Serviceorientierter Architektur (SOA) befassen. Es bie-


http://intranet.bit.admin.ch/dokumentation/02687/02690/02975/index.html?lang=de

http://intranet.bit.admin.ch/dokumentation/02687/02690/02975/index.html?lang=de


http://www.egovernment.ch/egov/00833/00834/index.html?lang=de


http://www.isb.admin.ch/themen/strategien/00070/index.html?lang=de&

http://www.isb.admin.ch/themen/standards/alle/03264/?lang=de



5/107


tet Definitionen für SOA-bezogene Begriffe, die im Rahmen der Bundesverwal-

tung eine spezielle Bedeutung haben. Für andere Begriffe (z.B. technischer

Art) wird auf öffentliche Quellen verwiesen.

http://www.isb.admin.ch/themen/standards/alle/05019/in-

dex.html?lang=de&download=NHzLp-

Zeg7t,lnp6I0NTU042l2Z6ln1acy4Zn4Z2qZpnO2Yuq2Z6gpJCEdn5,g2ym162ep

Ybg2c_JjKbNoKSn6A--

[ISB-SIP] Strategische Informatikplanung – Referenzhandbuch: Vorgehensmethodik der

strategischen Informatikplanung (SIP) des Bundes

[KS-EZV] Kontrollstrategie EZV

[LA-EZV] Leistungsauftrag 2013 - 2016 EZV, siehe

http://www.ezv.admin.ch/org/04134/04176/index.html?lang=de

[SIP-EFD] Strategische Informatikplanung EFD

[TarifV] Tarifnummern-Verzeichnis zum elektronischen Zolltarif Tares, siehe

http://www.ezv.admin.ch/pdf_linker.php?doc=tarif_verzeichnis&lang=de

[TechLK-BIT]

Technologielandkarte BIT

http://intranet.bit.admin.ch/dokumentation/02687/02690/05124/index.html?lang=de&down-

load=NHzLp-

Zeg7t,lnp6I0NTU042l2Z6ln1acy4Zn4Z2qZpnO2Yuq2Z6gpJCDfYB3fWym162epYbg2c_JjKbNoKS

n6A

[VAM-Bund] Vision Architekturmanagement Bund

[VDSG] Verordnung zum Bundesgesetz über den Datenschutz, siehe


[IT-V-BIT] IT-Vorgaben des BIT, siehe

http://intranet.bit.admin.ch/dokumentation/02687/02690/index.html?lang=de

[WIsB]

Weisungen des Bundesrates über die IKT-Sicherheit in der Bundesverwaltung,

siehe


[WRAF-EFD]

Weisung über die Referenzarchitektur für Fachanwendungen im Eidgenössi-

schen Finanzdepartement

Tritt per 01.01.2016 in Kraft

[WIT-EFD] Weisung über die Informatik und Telekommunikation im Eidg. Finanzdeparte-

ment

[ZG] Zollgesetz, siehe


[ZV] Zollverordnung, siehe


[ZS-EZV] Zielsetzungen der EZV für die nächsten zwei Jahre (Stand: September 2014)

http://intranet.ezv.admin.ch/ozd/strategie/00248/00423/index.html?lang=de&down-

http://www.isb.admin.ch/themen/standards/alle/05019/index.html?lang=de&download=NHzLpZeg7t,lnp6I0NTU042l2Z6ln1acy4Zn4Z2qZpnO2Yuq2Z6gpJCEdn5,g2ym162epYbg2c_JjKbNoKSn6A--




http://www.ezv.admin.ch/org/04134/04176/index.html?lang=de

http://www.ezv.admin.ch/pdf_linker.php?doc=tarif_verzeichnis&lang=de

http://intranet.bit.admin.ch/dokumentation/02687/02690/05124/index.html?lang=de&download=NHzLpZeg7t,lnp6I0NTU042l2Z6ln1acy4Zn4Z2qZpnO2Yuq2Z6gpJCDfYB3fWym162epYbg2c_JjKbNoKSn6A





http://intranet.bit.admin.ch/dokumentation/02687/02690/index.html?lang=de




http://intranet.ezv.admin.ch/ozd/strategie/00248/00423/index.html?lang=de&download=M3wBUgCt_8ulmKDu36WenojQ1NTTjaXZnqWfVpzLhmfhnapmmc7Zi6rZnqGkkIR3fXd8gY2f5qSenpXLztiMptegpaaNztCIn,agoKWM09PXylZzz55dqeA-



6/107


load=M3wBUgCt_8ulm-

KDu36WenojQ1NTTjaXZnqWfVpzLhmfhnapmmc7Zi6rZnqGkkIR3fXd8gY2f5qSenpXLztiMpteg-

paaNztCIn,agoKWM09PXylZzz55dqeA-






7/107

Inhaltsverzeichnis

1 Zusammenfassung 11

2 Einführung 12

2.1 Gegenstand der SOLL-Architektur ...................................................................... 12

2.2 Ziele der SOLL-Architektur .................................................................................. 17

2.3 Struktur des Dokuments ...................................................................................... 17

2.4 Adressaten des Dokuments................................................................................. 17

3 Methodische Grundlagen 18

3.1 Architekturentwicklung in der Bundesverwaltung ............................................. 18

3.2 Strategische Informatikplanung - SIP ................................................................. 19

3.3 Erarbeitung der SOLL-Architektur ...................................................................... 19

3.3.1 Vorgehen zur Herleitung von Geschäftsprinzipien .................................................. 20

3.3.2 Vorgehen zur Ableitung von Geschäftsfunktionen .................................................. 22

3.3.3 Vorgehen zur Ableitung von IT-Funktionen ............................................................. 22

3.3.4 Vorgehen zur Definition von IT-Prinzipien ............................................................... 23

4 SOLL-Architektur 24

4.1 Geschäftsarchitekturebene ................................................................................. 24

4.1.1 Geschäftsfelder ...................................................................................................... 24

4.1.2 Geschäftstreiber ..................................................................................................... 25

4.1.3 Geschäftsprinzipien ................................................................................................ 29

4.1.4 Geschäftsfunktionen ............................................................................................... 41

4.2 Informationssystemarchitektur ........................................................................... 56

4.2.1 IT-Prinzipien ........................................................................................................... 56

4.2.2 Geschäftsobjektkatalog .......................................................................................... 60

4.2.3 IT-Funktionen ......................................................................................................... 63

4.2.4 Anwendungen ........................................................................................................ 65

4.2.5 Vorgaben zur Informatiksicherheit für B2B und Portal ............................................ 79

4.3 Technologiearchitektur ........................................................................................ 81

4.3.1 Prinzipien ............................................................................................................... 81

4.3.2 Anforderungskategorien ......................................................................................... 82

4.4 Technologie Referenzmodell ............................................................................... 85

4.5 Abhängigkeiten .................................................................................................... 86

4.5.1 Anwendungen zu Technologie ............................................................................... 86

4.5.2 Entwicklung und Betrieb ......................................................................................... 86

5 Weitergehendes Potential der Architektur 88

6 Fazit 90

6.1 SOLL-Architektur GAR-EZV ................................................................................. 90

6.2 Übersicht über die SOLL-Architektur GAR-EZV ................................................. 91

6.3 Weiteres Vorgehen ............................................................................................... 92



8/107

7 Anhänge 93

7.1 Projektplan ............................................................................................................ 93

7.2 Organigramm des Projekts .................................................................................. 94

7.3 Methodik – Anhang .............................................................................................. 95

7.3.1 Tailoring GAR-EVZ von SIP & TOGAF-ADM .......................................................... 95

7.4 Strukturierte Interviews - Anhang ....................................................................... 95

7.4.1 Inhaltliche Struktur der Interviews ........................................................................... 95

7.4.2 Auswertung der Interviews ..................................................................................... 96

7.4.3 Interviewplanung .................................................................................................... 96

7.5 Geschäftsfunktionen – Anhang ........................................................................... 98

7.6 Beschreibung IT-Funktionen ............................................................................... 99



9/107

Abbildungsverzeichnis

Abbildung 1: Übersicht über die Dokumentenstruktur GAR-EZV 12

Abbildung 2: Architekturbausteine GAR-EZV 13

Abbildung 3: Zusammenhang Strategieebene mit der Geschäfts- und IT-Architekturebene 15

Abbildung 4: Abhängigkeit von Bedürfnissen zu Leistungszielen über Treiber 16

Abbildung 5: Anlehnung des Studienvorgehens an der ADM von TOGAF 18

Abbildung 6: Gesamtmodell der strategischen Informatikplanung 19

Abbildung 7: Erarbeitung der IT-SOLL-Architektur und Architekturvision 20

Abbildung 8: Vorgehen zur Herleitung der Geschäftsprinzipien 20

Abbildung 9: Herleitung der Geschäftsprinzipien über die Bedürfnisse der EZV 21

Abbildung 10: Vorgehen zur Ableitung der Geschäftsfunktionen 22

Abbildung 11: Herleitung IT-Funktionen 23

Abbildung 12: Geschäftsfelder 24

Abbildung 13: Auflistung der Geschäftsprinzipien aufgrund der Geschäftstreiber 29

Abbildung 14: Struktur eines Geschäftsprinzips 30

Abbildung 15: Prinzipen-Matrix 30

Abbildung 16: Übersicht Prinzipien EZV 31

Abbildung 17: IST-Geschäftsfunktions-Heat-Map 48

Abbildung 18: SOLL-Geschäftseigenschafts-Map 49

Abbildung 19: IST-Geschäftsfunktionsmodell 50

Abbildung 20: IST-Geschäftsfunktionsmodell 51

Abbildung 21: Geschäftsfunktionsmatrix 54

Abbildung 22: Wirkungsmatrix Geschäftsprinzipien 55

Abbildung 23: Anwendungslandschaft 66

Abbildung 24 - IT-Funktionen pro Anwendung 78

Abbildung 25: Technologielandkarte BIT 85

Abbildung 26: BIT Produktionslinien 87

Abbildung 27: Weitergehendes Potential der Architektur 88

Abbildung 28: Übersicht über die SOLL-Architektur GAR-EZV 91

Abbildung 29: Projektergebnisstruktur GAR-EZV 94

Abbildung 30: Organigramm GAR-EZV 94

Abbildung 31: Tailoring SIP & TOGAF-ADM für GAR-EZV 95

Abbildung 32: Inhaltliche Struktur der Interviews GAR-EVZ 95

Abbildung 33: Traceability von MA Aussagen (Anforderungen) zur Konsolidierung von Prinzipien 96

Abbildung 34: Auswahl der Befragten – Abdeckung EZV 97



10/107

Tabellenverzeichnis

Tabelle 1: Beschreibung Architekturbausteine GAR-EZV 14

Tabelle 2: Beschreibung Architekturbaustein IT-Prinzip GAR-EZV 15

Tabelle 3 Geschäftstreiberliste 28

Tabelle 4: Geschäftsprinzip Integration 32

Tabelle 5: Geschäftsprinzip Kooperation 34

Tabelle 6: Geschäftsprinzip Evolution 35

Tabelle 7: Geschäftsprinzip IT-for-Business 36

Tabelle 8: Geschäftsprinzip Zweckmässigkeit 37

Tabelle 9: Geschäftsprinzip Leistungsfähigkeit 38

Tabelle 10: Geschäftsprinzip Mobilität 39

Tabelle 11: Geschäftsprinzip Informationssicherheit 40

Tabelle 12: Beschreibung Geschäftsfunktionen 44

Tabelle 13: Beschreibung SOLL-Geschäftseigenschaften 47

Tabelle 14: Geschäftsprinzipien unterteilt in Kerngeschäft und Erfüllungsgrad 53

Tabelle 15: Prinzip D1 – Gemeinsame Nutzung der Daten 57

Tabelle 15: Prinzip D2 – Einheitliche Modelle 57

Tabelle 15: Prinzip D3 – Datensicherheit 58

Tabelle 15: Prinzip A1 – Fokussierung 58

Tabelle 15: Prinzip A2 - Wiederverwendbarkeit durch Modularität 59

Tabelle 15: Prinzip A3 - Plattformunabhängigkeit 59

Tabelle 15: Prinzip A4 - Unternehmensweite Integrationsplattform 59

Tabelle 15: Prinzip A5 - Web und Mobile 60

Tabelle 15: Geschäftsobjekte 62

Tabelle 16: Liste der IT-Funktionen 65

Tabelle 17: Bezug Architektur zu Businessprinzipien 69

Tabelle 18: Anwendungen 77

Tabelle 19: Allgemeine Anforderungen an Technologie-Komponenten 84

Tabelle 20: Umsetzungsbezogene Anforderungen 84

Tabelle 21: Übergreifendes Synergiepotential 89

Tabelle 22: Beschreibung IT-Funktionen 107



11/107

1 Zusammenfassung

Als Grundlage für die angestrebte SOLL-Architektur werden die Geschäftsprinzipien definiert. Daraus

werden im Verlauf des Projekts GAR-EZV die Geschäftsfunktionen und benötigten IT-Funktionen abge-

leitet. Diese wiederum bilden die Basis für die IT-Prinzipien.

Die Ergebnisse der strukturierten Interviews mit den Mitarbeitenden der Zollverwaltung bilden den Aus-

gangspunkt für die Bedürfniserhebung. Diese Mitarbeiterbedürfnisse sind angetrieben von sogenannten

Geschäftstreibern. Bedürfnisse entstehen zum Beispiel durch den Anstoss, vorgegebene Ziele zu errei-

chen, ohne dass die notwendigen Mittel zur Erfüllung verfügbar sind.

Diese konsolidierten und zusammengefassten Treiber führen zu acht Geschäftsprinzipien, welche auf

einer abstrahierten Ebene die Bedürfnisse zur optimalen Aufgabenerfüllung benennen.

Die SOLL-Architektur muss so aufgebaut sein, dass sie die Erreichung der übergeordneten Ziele ermög-

licht. Dazu benötigt die EZV unter anderem Flexibilität, Mobilität und Erweiterbarkeit. Diese muss auf

den heutigen Stärken aufbauen, wie gute Sprachkompatibilität oder hohen Automatisierungsgrad. Zu-

dem müssen erkannte Schwächen, zum Beispiel fehlende Mobilität des Arbeitsplatzes oder Unübersicht-

lichkeit bei den Applikationen ausgemerzt werden.

Mit gezielten Massnahmen kann die EZV von Datenauswertung und Datennutzung profitieren oder

durch vermehrten Kundeneinbezug Arbeitsaufwand einsparen. Zu berücksichtigen sind aber die stets

steigenden Schwierigkeiten bei der Integration und Sicherheitsgewährleistung.

Die ausgearbeitete SOLL-Architektur bietet der EZV die Chance, eine optimale IKT-Landschaft zu betrei-

ben, welche der EZV, ihren Kunden und Partnern effizienteres Arbeiten ermöglicht. Das Schaffen eines

einheitlichen Datenmodells für die gesamte EZV führt zu konsistenten und qualitativ besseren Daten.

Diese können einfacher und systematischer ausgewertet werden. So können zum Beispiel Muster er-

kannt werden, was eine erfolgreichere Risikoanalyse sicherstellt.

Die strukturiert abgelegten Daten unterstützen zudem das Open-Governement-Data Konzept, welches

Kunden und Partnern erlaubt, Daten der EZV wiederzuverwenden und zu nutzen.

Neue Anwendungen sind auf Funktionen und Daten ausgerichtet. Dadurch werden Redundanzen ver-

mieden. Eine Minimierung von Anwendungen und Datenbeständen führen letztendlich zu einer weniger

komplexen Architektur, Skaleneffekten und Kosteneinsparungen.

Die Schaffung eines EZV-weiten Portals wird den Kunden die Kommunikation mit den verschiedenen

Stellen der EZV erleichtern. Die Nutzung einer B2B-Komponente lässt den Einsatz von standardisierten

Schnittstellen zu, was den Datenaustausch vereinfacht. Davon profitiert die EZV sowohl in Zusammenar-

beit mit nationalen Partnern (z.B. Fahndungsdaten austauschen) als auch mit internationalen Partnern

(z.B. AEO Identitäten austauschen).

Die Ausrichtung auf Webtechnologien ermöglicht die mobile Nutzung der Anwendungen für Kunden aber

auch für EZV-Mitarbeiter. Auf mobilen Einsätzen können Daten effizienter und ohne Medienbrüche ab-

gefragt oder eingegeben werden. Dies führt zu weniger Doppelspurigkeiten und steigert die Effizienz und

Effektivität.

Mit einer modularen Struktur schafft die SOLL-Architektur mehr Flexibilität bei Anpassungen, womit

schlussendlich das Reagieren auf Anpassungen und neuen Trends vereinfacht und beschleunigt wird.



12/107

2 Einführung

Die SOLL-Architektur inklusive Architekturvision stellt, ausgehend von der IST-Architektur, das zweite

Lieferobjekt aus der Studie „Geschäftsprinzipien, IT-Architektur und Roadmap EZV“ dar. Als solches be-

fasst sich die Architekturvision mit den Grundsätzen der Geschäftsarchitektur sowie der Informationssys-

tems- und Technologiearchitektur der gesamten Zollverwaltung.

Abbildung 1: Übersicht über die Dokumentenstruktur GAR-EZV

2.1 Gegenstand der SOLL-Architektur

Als Eckpfeiler für die zukünftige Ausrichtung der Architektur werden sogenannte Geschäftsprinzipen und

-treiber hergeleitet, welche für die gesamte EZV verbindlich sind.

Die SOLL -Architektur gliedert sich nach TOGAF-ADM1 in die Ebenen Geschäftsarchitektur, Informati-

onssystemarchitektur und Technologiearchitektur. Um einen ersten, relevanten Überblick über die ge-

samte Architektur der EZV zu erhalten, werden die jeweiligen Ebenen nicht vollständig beschrieben. Da

der Fokus dieser Studie auf einer pragmatisch anwendbaren IT-Architektur zur Erstellung einer Architek-

tur-Roadmap liegt, werden die Architekturbausteine der Geschäftsarchitektur wie Prozesse, Organisa-

tion, Funktion oder Lokation nicht analysiert [GAR-PAUF]. Stattdessen werden aufgrund der erhobenen

Bedürfnisse und zukünftigen Chancen Geschäftsprinzipien und -treiber definiert, welche die Ableitung

von Geschäftsfunktionen erlauben. Dadurch ist die Verbindung zur IT-Architektur über die abgeleiteten

Funktionen sichergestellt.

1 Siehe Kapitel 3



13/107

Abbildung 2: Architekturbausteine GAR-EZV

In der folgenden Tabelle sind die Architekturbausteine, welche in Abbildung 2 dargestellt sind, in Bezug

auf die Verwendung im Rahmen dieser Studie definiert.

Architekturbaustein Beschreibung

Geschäftsarchitektur

Architektur, welche die organisatorische und räumliche Struktur, die Zuständigkeiten der Ge-

schäftsträger (Bundesrat, Departemente, Ämter, u. s. w. ), deren Geschäftsprozesse und die

von ihnen produzierte und verwaltete Information beschreibt und welche die Vorgaben für

die Informatikarchitektur im engeren Sinne definiert und sich nach der Geschäftsstrategie

richtet2.

Informationssystem-

architektur

Übersicht aller Anwendungen eines Informationssystems und der von ihnen beeinflussten

Aufbau- und Ablauforganisation2.

Technologiearchitektur Minimaler Satz von Regeln der den Zusammenhang, die Wechselwirkungen und Abhängig-

keiten der System Komponenten festlegt2.

Geschäftsprinzip

Geschäftsprinzipien beschreiben, wie die EZV den Leistungsauftrag erfüllen soll und bilden

eine Grundlage zur Harmonisierung der Entscheidungsfindung. In dieser Studie bilden die

Geschäftsprinzipien die Grundlage zur Ableitung von IT-Prinzipien.

Geschäftstreiber

„Ein Geschäftstreiber bzw. ein Faktor ist in TOGAF eine Bedingung, die das Unternehmen

zum Definieren seiner Ziele anhält.“3. Geschäftstreiber werden in dieser Studie aus den erho-

benen Bedürfnissen der Mitarbeitenden konsolidiert und mit den übergeordneten Zielen der

EZV abgeglichen. Zudem wurde zur Evaluation von EZV-externen Treibern ein Workshop

auf Stufe Geschäftsleitung EZV durchgeführt. Diese Treiber sind in den Geschäftsprinzipien

integriert und ermöglichen die Beschreibung der konsequenten IT-SOLL-Ziele.

Geschäftsfeld Die Geschäftsfelder dienen zur Kategorisierung der Anwendungen. Sie bilden den Rahmen

2 Quelle: Informatik-Terminologie Bund http://www.isb.admin.ch/glossar/ | 31.07.2015, 09:25 Uhr 3 Quelle: http://www-01.ibm.com/support/knowledgecenter/SS6RBX_11.4.2/com.ibm.sa.togaf9.doc/topics/c_definitions.html | 31.07.2015,

09:34 Uhr



14/107


auch für die spätere SOLL-Betrachtung, damit ist die Vergleichbarkeit zwischen IST und

SOLL sichergestellt.

Geschäftsfunktion

Geschäftsfunktionen beschreiben, wie eine Aufgabe auf der Ebene Geschäftsarchitektur

ausgeführt werden soll und sind abgeleitet aus den Geschäftsfeldern resp. -aufgaben.

Die Basis bilden die in Redesign Fracht erarbeiteten IS-Services sowie die System Use

Cases (SUC) aus VSP. Durch die funktionale Einordnung der Anwendungen können funktio-

nale Redundanzen oder fehlende Funktionen identifiziert werden.

Geschäftsaufgaben (Geschäftsfunktionsgruppen) stellen eine funktionale Differenzierung

von Geschäftsfelder dar und fassen Geschäftsfunktionen in Gruppen zusammen.

Eine eher abstrakte Darstellung kommt bei den SOLL-Geschäftseigenschaften zur Anwen-

dung. Sie beschreiben im Prinzip wie eine Aufgabe oder Funktion ausgeführt werden soll

und sind abgeleitet aus den Geschäftsfeldern und -aufgaben. Die strategischen Geschäfts-

funktionen beschreiben die gewünschten oder notwendigen Fähigkeiten zum zukünftigen

Aufgabenvollzug und werden aus der Kombination von Treibern und Geschäftsfunktionen

gebildet.

Geschäftsobjekt

Ein Geschäftsobjekt ist eine formale Repräsentation eines konkreten Fachbegriffs4. Die Ba-

sis bilden die in Redesign Fracht und VSP erarbeiteten Objekte. Die Zuordnung der Ge-

schäftsobjekte auf die Applikationslandschaft lässt Schlüsse zur Datenhaltung (Redundan-

zen) und der Anwendung von Masterdata Management zu.

Anwendung Anwendungen sind konkrete Implementierungen von Funktionalitäten. Sie enthalten die kon-

krete technische Beschreibung.3

IT-Funktion Die IT-Funktionen beschreiben die notwendigen Fähigkeiten, welche auf der Ebene der IS

und Technologie-Architektur erforderlich sind um den Leistungsauftrag zu erfüllen.

Plattformdienst

Ein Plattformdienst stellt die konkrete Beschreibung einer Infrastrukturfähigkeit anhand eines

konkreten Interfaces (technische Beschreibung) und der verantwortlichen Organisationsein-

heit dar.3

Netzwerkdienst Ein Netzwerkdienst beschreibt die konkrete technische Umsetzung.3

Tabelle 1: Beschreibung Architekturbausteine GAR-EZV

Die erhobenen und validierten Geschäftstreiber werden in zukunftsfähige Geschäftsprinzipen konsoli-

diert und bilden die Verbindung der Geschäftsarchitektur mit der bestehenden Strategieebene. Abbil-

dung 3 stellt die übergeordnete Strategieebene im Zusammenhang mit der Geschäftsarchitekturebene

und den IS- und Technologie-Architekturebenen dar.

4 Quelle: [ISB-SOA-GLOSSAR]



15/107

Abbildung 3: Zusammenhang Strategieebene mit der Geschäfts- und IT-Architekturebene

Aufgrund der definierten Geschäftsprinzipien werden für die EZV richtungsweisende IT-Prinzipien defi-

niert.


IT-Prinzip

Das IT-Prinzip beschreibt analog zum Geschäftsprinzip wie die IS- und Technologie-Ar-

chitektur den Betrieb dazu befähigen kann die Aufgaben zukünftig zu erfüllen und bildet

die Grundlage zur Harmonisierung der Architekturentscheidungsfindung.

Tabelle 2: Beschreibung Architekturbaustein IT-Prinzip GAR-EZV

Durch die Verbindung der Geschäftstreiber mit den Geschäftszielen der EZV soll sichergestellt werden,

dass die erarbeitete SOLL-Architektur auf den Leistungsauftrag, die Geschäftsziele sowie die geltenden

Rahmenbedingungen abgestimmt ist. Dies ermöglicht ebenfalls die Ableitung der IT-Architektur von der

erhobenen Geschäftsarchitektur unter Ausschluss der Prozesse, Funktionen und der Geschäftsorgani-

sation.

Die beschriebenen Geschäftsprinzipien werden dabei in die bestehenden Strategieelemente wie Vision,

Leistungsauftrag und Rahmenbedingungen eingebettet. Zusammen mit dem durchgeführten Workshop

zu externen Geschäftstreibern der EZV ergibt sich damit ein Top-down Vorgehen zur Herleitung von Ge-

schäftstreibern und -prinzipien.



16/107

Abbildung 4: Abhängigkeit von Bedürfnissen zu Leistungszielen über Treiber

Die Studie befasst sich im Weiteren mit der Bottom-up Herleitung der Geschäftstreiber und -prinzipien

über die Erhebung von bestehenden sowie potentiellen Bedürfnissen von Mitarbeitenden. In Abbildung 4

ist die Abhängigkeit von Bedürfnissen zu Leistungszielen über die erarbeiteten Geschäftstreiber in vier

Punkten beschrieben. Punkt eins zeigt die Erhebung der Bedürfnisse von Mitarbeitenden und indirekt

von Kunden sowie Partnern der EZV auf. Das Ableiten der Bedürfnisse in Geschäftstreiber erfolgt dabei

über die Evaluation der Ursache von konkreten Bedürfnissen. Punkt zwei erläutert die Auswirkung von

Geschäftstreibern auf die EZV als Bedingung, welche zur Definition ihrer Ziele anhält. Die Auswirkungen

werden dabei auf die bestehenden Leistungsziele beschrieben und zu einem späteren Zeitpunkt in kon-

krete IT-Ziele umformuliert. Diese Ableitung wird in Punkt drei dargestellt. Zuletzt, dargestellt in Punkt 4,

werden die Treiber in allgemeingültige und umfassende Prinzipien konsolidiert.

Aus den definierten Geschäftsprinzipien werden die für die EZV benötigten Geschäftsfunktionen ab-

geleitet. Diese bilden die Basis für die IT-Funktionen, welche zum Erlangen der Geschäftsfunktionen

nötig sind. Aufgrund dieser werden die IT-Prinzipien für die SOLL-Architektur definiert.



17/107

2.2 Ziele der SOLL-Architektur

Das unmittelbare Ziel dieses Dokuments ist die Festlegung der Geschäfts- und IT-Prinzipien EZV, wel-

che die Ableitung einer homogenen und strukturierten SOLL-Architektur inklusive Architekturvision bis

2025 erlauben. Dies mit dem nachgelagerten Ziel, eine Ablösungs- und Migrations-Roadmap inklusive

Transitionsarchitekturen von 2017 bis 2020 sowie einen Masterplan zur Umsetzung der Transitionsarchi-

tekturen inklusive Ressourcenbedarf für die konkrete Beantragung von IKT-Mitteln für die Jahre 2017 bis

2025 zu erstellen.

Der Nutzen der SOLL-Architektur widerspiegelt sich demnach einerseits in der Bereitstellung einer Ge-

samtübersicht der Architekturvision bis 2025 und andererseits in der Ermöglichung einer mittel- bis lang-

fristigen Planung der IKT-Projekte sowie einer nachhaltigen Verwendung von IKT-Mitteln. Damit wird ne-

ben einer erhöhten Transparenz auch die Planungssicherheit sowie die Schätzgenauigkeit in Bezug auf

IKT-Mittel erhöht.

Die SOLL-Architektur gilt ebenfalls als Grundlage zur strategischen Informatikplanung der EZV. Sofern

die erarbeitete Architektur sowie die definierten Architekturbausteine in regelmässigen Iterationen revali-

diert werden und somit an Gültigkeit und Aussagekraft zunehmen, ist die EZV befähigt, ihr IKT-Portfolio

strategisch zu planen.

2.3 Struktur des Dokuments

Das vorliegende Dokument gliedert sich zum momentanen Zeitpunkt in vier Kapitel (3-6) sowie einen

Anhang. Zunächst werden in Kapitel 3 die methodischen Grundlagen für die Erarbeitung der SOLL-Ar-

chitektur vorgestellt. Das Kapitel 4 skizziert die Geschäftsarchitekturebene der SOLL-Architektur. Diese

beruht auf Geschäftsprinzipien und -treibern, welche aus den erhobenen Bedürfnissen abgeleitet wer-

den. Im Kapitel 5 wird die Verbindung zu der Weisung über die Referenzarchitektur für Fachanwendun-

gen im Eidgenössischen Finanzdepartement hergestellt, die EFD-übergreifende Prinzipien in den ver-

schiedenen Architekturdomänen definiert mit dem Ziel definierte Geschäftsobjekte und Funktionen ein-

heitlich zu handhaben oder gar gemeinsam zu führen. Im Kapitel 6 wird das Fazit gezogen und das wei-

tere Vorgehen beschrieben.

2.4 Adressaten des Dokuments

Die SOLL-Architektur und Geschäftsprinzipien richten sich an alle Anspruchsgruppen der Studie GAR-

EZV. Primärer Adressat ist der Projektausschuss dieser Studie sowie im Weiteren die Geschäftsleitung

der EZV.



18/107

3 Methodische Grundlagen

Das folgende Kapitel beschreibt die Methoden sowie deren grundlegenden Anwendung zur Erreichung

der gesetzten Ziele. Um die für diese Studie relevanten Ziele mit höchster Effizienz zu erreichen, wurden

die angewandten Methoden auf die spezifischen Bedürfnisse zugeschnitten. Die Beschreibung der ein-

zelnen Methoden sowie deren Abhängigkeiten zueinander sollen die konkrete Aussagekraft und Limita-

tion dieser Studie verdeutlichen.

3.1 Architekturentwicklung in der Bundesverwaltung

Die Studie stellt primär ein Architekturentwicklungsprojekt dar und soll deshalb nach der vom ISB5 dafür

vorgesehenen Methodik ADM aus TOGAF abgewickelt werden.

Demzufolge gliedert sich das Vorgehen in folgende Etappen:

• Architekturvision, entsprechend Phase A aus der ADM

Die Vision wird anhand von erarbeiteten Geschäfts-

prinzipien & Geschäftsfunktionen (Abb. 3) abgeleitet

• Geschäftsarchitektur, entsprechend Phase B aus der

ADM

Die Phase wird durch die Definition von Geschäftsprin-

zipien abgekürzt

• Informationssystemarchitektur, entsprechend Phase C

aus der ADM

• Technologiearchitektur, entsprechend Phase D aus der

ADM

• Umsetzungsplanung, umfassen die beiden Phasen E und

F aus der ADM

Abbildung 5 illustriert das Vorgehen anhand der offiziellen ADM-Grafik von TOGAF. Im Rahmen der Stu-

die werden lediglich die hervorgehobenen Phasen durchlaufen. Zudem werden die ersten beiden Pha-

sen (Architekturvision und Geschäftsarchitektur) in einem abgekürzten Verfahren erarbeitet. Dieses Vor-

gehen wurde mit der Projektsteuerung abgesprochen und ist angepasst auf die Zielsetzung, um den be-

schriebenen Leistungsumfang in der vorgesehenen Zeit erfolgreich zu erfüllen. Die konkrete Anwendung

der TOGAF-ADM Methode wird in Kapitel 3.3 detailliert erklärt.

5 http://www.isb.admin.ch/themen/methoden/00798/index.html?lang=de | 31.07.2015, 09:35 Uhr

Abbildung 5: Anlehnung des Studienvorgehens an

der ADM von TOGAF



19/107

3.2 Strategische Informatikplanung - SIP

Die in dieser Studie erarbeiteten Ergebnisse sollen der EZV als Grundlage zur strategischen Informatik-

planung dienen und damit einen zusätzlichen Mehrwert schaffen. Zu diesem Zweck werden die für die

Grundlagenerarbeitung relevanten Module aus der Methodik SIP des ISB in dieser Studie aufgenom-

men. Die Module der SIP sind in Abbildung 6 mit Bezug auf die Studie dargestellt.

Abbildung 6: Gesamtmodell der strategischen Informatikplanung

3.3 Erarbeitung der SOLL-Architektur

Gemäss TOGAF-ADM folgt die Erarbeitung der SOLL-Architektur im Grundsatz vier Schritten. Das über-

geordnete Ziel ist die Erarbeitung einer Architekturvision, welche bis ins Jahr 2025 die grundsätzlichen

Ziele und Rahmenbedingungen in Bezug auf die IKT der EZV darstellen soll.

In einem ersten Schritt werden Geschäftsprinzipien abgeleitet. Diese Geschäftsprinzipien sind, basie-

rend auf den spezifischen Bedingungen und dem konkreten Leistungsauftrag der EZV, ausgeführt und

sollen durch die Integration der SIP-Module eine möglichst langfristige Aussage ermöglichen. Von den

Geschäftsprinzipien können die notwendigen Geschäftsfunktionen abgeleitet werden, welche zur Erfül-

lung der heutigen sowie zukünftigen Aufgaben und der Zielsetzung der kommenden Jahre notwendig

sind. Damit wird die Unternehmensarchitektur nach TOGAF-ADM spezifisch für die EZV beschrieben,

welche der zukünftigen Ausrichtung der IT- SOLL -Architektur dient.

Basierend auf den definierten Geschäftsfunktionen können die dazu assoziierten IT-Funktionen definiert

werden, welche zur Umsetzung dieser Geschäftsfunktionen notwendig sind. Durch Konsolidierung die-

ser IT-Funktionen können für die EZV allgemeingültige und richtungsweisende IT-Prinzipien beschrieben

werden.



20/107

Diese IT-Prinzipien sollen die Planung und Umsetzung von IKT-Projekten zukunftsweisend steuern um

die IKT der EZV auf künftige Anforderungen vorzubereiten und die heute heterogene Anwendungsland-

schaft zielgerichtet zu harmonisieren.

Die Aussagekraft dieser IT-Prinzipien für die kommenden 10 Jahre wird massgeblich durch die Legitimi-

tät der Geschäftsprinzipien und -Funktionen definiert. Ändert sich die Unternehmensarchitektur durch

interne oder externe Faktoren, muss sich ebenfalls die IT-SOLL-Architektur anpassen.

Abbildung 7: Erarbeitung der IT-SOLL-Architektur und Architekturvision

Mittels IT-Funktionen und -Prinzipien kann für die EZV die SOLL-Architektur einschliesslich jährlichen

Transitionsarchitekturen beschrieben werden. Ausgehend von der SOLL-Architektur und der parallel er-

arbeiteten Ist-Architektur ermöglichen die Transitionsarchitekturen die Erstellung einer Roadmap inklu-

sive einer konkreten Umsetzungsplanung zur Erreichung der Architekturvision bis 2025.

3.3.1 Vorgehen zur Herleitung von Geschäftsprinzipien

Als Basis für die SOLL-Architektur wurden EZV-relevante Geschäftsprinzipien hergeleitet. Die dazu not-

wendige Information wurde mittels strukturierten Interviews mit Mitarbeitenden erhoben. Die Interviews

ermöglichten die Erhebung konkreter Bedürfnisse einer möglichst repräsentativen Auswahl von Mitarbei-

tenden und die Konsolidierung dieser Bedürfnisse in Geschäftsprinzipien (siehe Kapitel 4.1.3).

Abbildung 8: Vorgehen zur Herleitung der Geschäftsprinzipien



21/107

Die Herleitung der Geschäftsprinzipien ist aufgeteilt in vier Schritte und beginnt mit der Validierung be-

stehender Informationen zur IST-Architektur und der Erhebung von Daten zur Erstellung der Heat-Map.

Ausgehend von konkreten Stärken und Schwächen der bestehenden IKT sowie betrieblichen Hindernis-

sen wurden Anforderungen zur SOLL-Architektur erhoben. Zusätzlich wurden Anforderungen resp. Be-

dürfnisse der wichtigsten Stakeholder mittels Befragung der Mitarbeitenden der EZV aufgenommen.

Diese Bedürfnisse wurden danach in Treibern konsolidiert. Diese Treiber bilden die inhaltliche Grund-

lage zur Beschreibung der Geschäftsprinzipien und stellen die Schnittstelle von den Bedürfnissen der

Mitarbeitenden und Stakeholder der EZV zu den Geschäftsprinzipien her.

Abbildung 9: Herleitung der Geschäftsprinzipien über die Bedürfnisse der EZV

Die Bedürfnisse, wie in Abbildung 9 dargestellt, ergeben sich aus der Einwirkung des Umfeldes, den

Aufgaben und des Leistungsauftrags der EZV auf die Mitarbeitenden. Die Geschäftstreiber bilden zu-

sammen mit den Geschäftsprinzipien einen wichtigen Baustein, welcher die zukünftige Unternehmensar-

chitektur der EZV widerspiegelt. Die Bedürfnisse der Mitarbeitenden der EZV wurden mittels strukturier-

ten Interviews, wie in Punkt 1 dargestellt, erhoben. Zudem hat die Geschäftsleitung der EZV in einem

strukturierten Workshop die wichtigsten externen Treiber und zukünftigen Trends evaluiert. Zusammen

mit dem bestehenden Leistungsauftrag der EZV ergeben die Bedürfnisse, die externen Treiber und zu-

künftigen Trends ein Gesamtbild für die Ableitung der Prinzipien.

Die Auswahl der Befragten sowie weitere Details zum Vorgehen der strukturierten Interviews sowie des

Workshops sind im Anhang Kapitel 7.4 erläutert.

Auf Basis der Ergebnisse der Mitarbeiterbefragungen werden die Bedürfnisse extrahiert. Diesen lie-

gen als Ursache sogenannte Geschäftstreiber zu Grunde Ergänzt werden diese Geschäftstreiber

durch einen Abgleich mit den Geschäftszielen der EZV. Die finalen Treiber werden konsolidiert und

verdichtet, was zu zukunftsorientierten Geschäftsprinzipien führt.



22/107

3.3.2 Vorgehen zur Ableitung von Geschäftsfunktionen

Durch die Definition relevanter Geschäftstreiber sowie die Bestimmung von Geschäftsfeldern und -auf-

gaben können die strategischen Geschäftsfunktionen der EZV abgeleitet werden. Die Geschäftsaufga-

ben wurden definiert aufgrund strategischer Geschäftsfelder der EZV und sind abgestimmt mit der heuti-

gen Prozesslandkarte der EZV sowie dem Leistungsauftrag. Die Geschäftsfelder und –aufgaben sind

beschrieben unter Kapitel 4.1.1.

Abbildung 10: Vorgehen zur Ableitung der Geschäftsfunktionen

3.3.3 Vorgehen zur Ableitung von IT-Funktionen

IT-Funktionen wurden anhand folgender Ergebnisse und Inputs hergeleitet:

1. Re-Design Fracht - Information System-Services (IS-Services). Diese stellen in sich geschlos-

sene, wiederverwendbare IT-Funktionalitäten zur (Teil-)Automatisierung von Geschäftsprozessen

dar.

2. Aus dem VSP Programm wurden ferner aus den Funktionsblöcken (Ein Funktionsblock ist eine

Zusammenfassung von Funktionalitäten zu einem spezifischen Themenbereich.) die IT-Funktio-

nen abgeleitet und nach dem jeweiligen Funktionsblock benannt.

3. GAR-EZV IST-Geschäftsarchitektur Level-1 Geschäftsfunktionen

4. GAR-EZV SOLL-Geschäftsarchitektur Geschäftseigenschaften

5. Input aus dem GAR-EVZ Kernteam, von den Applikationsverantwortlichen, Informatikleitern und

Fachspezialisten.



23/107

1. IS-Architektur Re-Design Fracht

2. Programm VSP - Funktionsblöcke

4. SOLL-Geschäftseigenschaften

IT-Funktionen3. IST-Level-1-Geschäftsfunktionen

5. Kernteam, Fachexperte, Fachverantwortliche

Abbildung 11: Herleitung IT-Funktionen

3.3.4 Vorgehen zur Definition von IT-Prinzipien

Die Daten-, Anwendungs- und Technologie-Prinzipien wurden auf der Basis der BIT IT-Architektur-Prin-

zipien [BIT A-Prinzipien] erstellt. Dabei wurde darauf geachtet, dass die gewählten Prinzipien auf GAR-

EVZ abgestimmt sind. Weiter wurden sichergestellt, dass es keine Widersprüche zu den in Vernehmlas-

sung befindlichen Prinzipien der Referenzarchitektur für Fachanwendungen EFD bestehen.



24/107

4 SOLL-Architektur

Die SOLL-Architektur besteht, wie in Kapitel 2 detaillierter beschrieben, aus einer Geschäftsarchitekture-

bene, Informationssystemarchitekturebene und einer Technologiearchitekturebene. In einer ersten

Phase werden nach definiertem Vorgehen die Geschäftstreiber und Geschäftsprinzipien erarbeitet. Zu-

sammen mit den in Kapitel 4.1.1 definierten Geschäftsfeldern können in einer nächsten Phase die rele-

vanten Geschäftsfunktionen abgeleitet werden. Im derzeitigen Stand des Dokumentes sind die Ge-

schäftstreiber definiert und beschreiben und erlauben bereits die Formulierung von Auswirkungen, resp.

Zielsetzungen einer SOLL-Architektur im Hinblick auf die Informationssystem- und Technologiearchitek-

turebenen. Zudem sind die erhobenen Bedürfnisse und Ideen der Mitarbeiter aus den Interviews in acht

zukunftsweisenden Geschäftsprinzipien konsolidiert und strukturiert dargestellt.

4.1 Geschäftsarchitekturebene

4.1.1 Geschäftsfelder

Zur Zuordnung der Architekturbausteine in der Beschreibung der SOLL-Architektur werden die Tätigkei-

ten der EZV in die drei Geschäftsbereiche Führung, Operatives Geschäft und Unterstützung unterteilt.

Diese Unterteilung beruht auf der heutigen Prozesslandkarte resp. deren Unterteilung in Führungs-, ope-

rative (Produktgruppen EZV) und Unterstützungsprozesse. Der Fokus wird dabei auf den Geschäftsbe-

reich Operatives Geschäft gelegt. Die beiden Geschäftsbereiche Führung und Unterstützung werden für

die Erarbeitung der SOLL- und IST-Architektur nicht weiter betrachtet.

Damit wird die Vergleichbarkeit sichergestellt und die spätere GAP-Analyse erleichtert. Der Inhalt der

einzelnen Geschäftsfelder wird nachfolgend kurz beschrieben.

Abbildung 12: Geschäftsfelder



25/107

Warenverkehr Grenze

Beinhaltet alle Hauptprozesse und Funktionen zur Abwicklung des grenzüberschreitenden Warenver-

kehrs. Dabei werden sowohl die typischen Frachtthemen als auch die auf Warenverkehr bezogenen Pro-

zesse und Funktionen des Reiseverkehrs subsummiert (z.B. Überprüfung von Fahrzeugen).

Personenverkehr

Der Personenverkehr umfasst alle Hauptprozesse und Funktionen, die für die Abwicklung des Personen-

verkehrs erforderlich sind.

Abgaben

Beinhaltet alle Hauptprozesse und Funktionen zur Abwicklung und Erhebung von Steuern und Len-

kungsabgaben (z.B. MinöSt, LSVA, usw.)

Shared Services (allgemeine Dienstleistungen)

Dieser Domäne sind die typischen „Querschnittsfunktionen“ zugeteilt, welche für die Kernprozesse

gleichermassen wichtig sind, allerdings aufgrund ihrer Charakteristik abgegrenzt werden können. Als

Beispiel kann die Tätigkeit Finanzmanagement im Zusammenhang mit einem Einfuhrprozess aufgeführt

werden. Der Hauptprozess nimmt die Anmeldung der Ware entgegen, kontrolliert diese und legt die Ab-

gaben fest. Das Einfordern der „Abgaben“ wird nachfolgend von der unterstützenden Tätigkeit Abgaben

erheben wahrgenommen.

Die Geschäftsfelder bilden den Rahmen um die IST-Architektur mit der SOLL-Architektur zu verglei-

chen. Sie sind mit der Prozesslandkarte der EZV gemappt, und erlauben daher bei Bedarf den zu-

künftigen Einschluss der Prozesse in die Geschäftsarchitektur.

4.1.2 Geschäftstreiber

Als ein Geschäftstreiber wird etwas in einer Geschäftsorganisation angesehen, das Neues entstehen

lässt, motiviert oder auch eine Veränderung antreibt. Geschäftstreiber können intern sein, dann werden

sie oft als Anspruch definiert (z.B. Rentabilität) oder auch extern wirken, als Triebkräfte des Wandels

(z.B. wirtschaftliche oder politische Veränderungen).

Als Basis für die Erhebung der Geschäftstreiber in der EZV dienen unterschiedliche Quellen:

Zum einen (Bottom-up-Ansatz) wurden bei über 50 EZV-Mitarbeitenden aus unterschiedlichsten Berei-

chen und Stufen Interviews zur aktuellen und zukünftigen IKT-Situation durchgeführt. Eine erste Aus-

wahl an Geschäftstreibern, welche als Basis durch das Kernteam GAR-EZV erstellt wurde, konnte mit-

tels der durchgeführten Interviews geprüft und validiert resp. ergänzt und angepasst werden. Die Anzahl

Nennungen der einzelnen Treiber bestimmt die Relevanz respektive Wichtigkeit. Thematisch gruppiert

ergeben die Geschäftstreiber die Basis für die Geschäftsprinzipien.



26/107

Zum anderen wurden Treiber aus dem Strategiepapier der EZV (Leistungsauftrag 2013 – 2016) abgelei-

tet (Top-down-Ansatz). Dazu diente die Lagebeurteilung6 sowie die Ziele der Produktegruppen 1 – 47.

Folgende Geschäftstreiber wurden identifiziert:

Treiber Beschreibung Herkunft

Interoperabilität Die Fähigkeit der Zusammenarbeit von verschiedenen Systemen, Techni-

ken und Organisationen ist gewährleistet. Dazu werden gemeinsame

Standards eingehalten.

Interview

Durchgängigkeit Die Übergabe von Informationen inkl. der Zuständigkeit ist organisato-

risch und systemübergreifend jederzeit für zollinterne Stellen, Kunden

und Partner nachvollziehbar.

Interview

Konsistenz Eine strukturierte und vollständige Datenbewirtschaftung ist gegeben. Der

Datenbezug ist für die relevanten Geschäftstätigkeiten jederzeit erhältlich.

Interview

Auswertbarkeit Korrekte Datenverknüpfung und -Aufbereitung für geschäftsrelevante

Auswertungen inklusive Integration des Performance Management Sys-

tem ermöglicht der EZV eine erhöhte Steuerbarkeit und ermöglicht eine

transparente Leistungserbringung.

Interview

Systemintegration Für die Geschäftstätigkeit relevanten Daten werden einbezogen und er-

möglichen nötige Verbindungen zu relevanten Systemen.

Interview

Vereinbarung Das Leistungsangebot inkl. gesetzlichen Richtlinien ist dem Partner klar

und in zweckmässiger Granularität bekannt und ist in der Anwendungs-

landschaft der EZV eingebettet.

Interview

Kommunikation Informationsaustausch erfolgt auf unterschiedlichen Kanälen, sowohl in-

nerhalb der EZV sowie mit den beteiligten Partnern.

Interview

Internationale Beteiligung Das aktive Mitwirken beim Aushandeln von Freihandelsabkommen sowie

die Sicherstellung des Vollzugs sind sichergestellt. Internationale Eins-

ätze zur Sicherung der Aussengrenzen des Schengen-Raums, die Bun-

desstrategie „Integrierte Grenzkontrolle“ sowie die internationale Zusam-

menarbeit im Rahmen der schweizerischen Aussen-, Friedens-, Sicher-

heits- und Handelspolitik gemäss Botschaft vom 15. Februar 2012 über

die internationale Zusammenarbeit 2013-2016 sind gewährleistet.

Leistungsauftrag

Nationale Zusammenarbeit Die EZV wird im Sicherheitsverbund Schweiz als unverzichtbarer Teil

wahrgenommen, hat Einsitz in die entsprechenden Gremien und begleitet

die Entscheidungsprozesse der ökologischen Steuerreform sowie der

Energieabgabe im Rahmen der Energiestrategie 2050 aktiv.

Leistungsauftrag

Flexibilität Bedürfnisse der Geschäftstätigkeiten können dank portierbarer und ska-

lierbarer IT zeitgerecht modular erweitert resp. mehrfach verwendet wer-

den.

Interview

Innovation Neues und Weiterentwicklungen im Technologiesektor und auch im Un-

terhaltungssektor schlagen sich vermehrt in der Geschäftswelt nieder.

Solche Neuerungen müssen laufend verfolgt und beurteilt werden. Je frü-

her eine Beeinflussung für die EZV erkannt wird, desto besser kann diese

geplant werden.

AGBA

Komplexität Die Vielschichtigkeit von schwer verständlichen Systemen Prozessen und Interview

6 http://www.ezv.admin.ch/org/04134/04176/index.html?lang=de | Leistungsauftrag 2013 – 2016, Kapitel 1.1 Strategie, 14.07.2015, 15:42 Uhr 7 http://www.ezv.admin.ch/org/04134/04176/index.html?lang=de | Leistungsauftrag 2013 – 2016, Kapitel 1.3 Produktegruppen, 14.07.2015, 15:55 Uhr



27/107


Tätigkeiten ist in logische und klare Einzelkomponente aufgeteilt und las-

sen sich einfach pflegen.

Steigerungsfähigkeit Monotone und sich wiederholende Geschäftstätigkeiten werden durch

den Einsatz von IT-Systemen unterstützt, vereinfacht oder von ihnen

komplett selber ausgeführt, sofern ein zeitlicher Gewinn oder aber auch

eine Kostenersparnis zur Folge haben.

Interview

Benutzerfreundlichkeit IT unterstützte Geschäftstätigkeiten sind für alle Anwender ohne Ein-

schränkungen zugänglich, können einfach mit den benötigten Ausgabe-

medien bedient werden und führen zu gesteigerter Anwenderzufrieden-

heit

Interview

Verständlichkeit Eine für den Anwender selbständig erlernbare und intuitiv anwendbare

Benutzerschnittstelle zu IT-System, die visuell gängigen und alltäglichen

Anwendungen entspricht. Einfache und verständliche Informationsaufbe-

reitung ermöglichen dem Anwender gezielt seine Tätigkeit auszuführen.

Interview

Systemverfügbarkeit Der Anwender kann ohne zeitliche Einschränkung die Ausübung seiner

Geschäftstätigkeit wahrnehmen.

Interview

e-Gov Die Strategie des Bundes im Bereich e-Government wird weiter umge-

setzt; die Interoperabilität mit den internationalen Projekten e-Customs

und Globally Networked Customs ist sichergestellt.

Leistungsauftrag

Öffentliche

Anerkennung

Die Bedürfnisse der Gesetzgebung inkl. definierten Rahmenbedingungen

und Vorgaben werden in der geforderten Qualität berücksichtigt.

Interview

Konformität Klare Vorgaben für Strafmasse und Einschränkungen werden eingehal-

ten.

Interview

Nutzbarkeit Die grösstmögliche Nutzbarkeit und der grösstmögliche Nutzen von IT-

Anwendungen, Gerätschaften und Infrastruktur werden evaluiert und be-

rücksichtigt.

Interview

Strategie Eine langfristige Planung der IKT Mittel ist möglich und die Ausrichtung

ist klar.

Die baulichen und betrieblichen Massnahmen zur Beschleunigung der

Grenzabfertigungen (Transito) sind gemäss Strategiepapier ‚Abfertigung

bei Strassenzollämtern‘ mit den Strategiegrundsätze der Kontrollstrategie

im Handelswarenverkehr berücksichtigt (Handelswarenstrategie).

Interview und

Leistungsauftrag

Anforderungen Die Veranlagungsprozesse werden unter Berücksichtigung der Anforde-

rungen der Kunden weiter entwickelt, administrative Hürden für die Unter-

nehmen und Kosten gesenkt.

Leistungsauftrag

Einnahmen Der Bund erhält die ihm zustehenden Einnahmen. Die Kunden melden

korrekt und vollständig an.

Leistungsauftrag

Wirtschaft Die importierende und exportierende CH-Wirtschaft ist im internationalen

Handel konkurrenzfähig, die Attraktivität des Wirtschaftsstandorts

Schweiz ist unterstützt und ein fairer Wettbewerb ist gewährleistet. Kun-

den nehmen den Veranlagungsprozess als rasch und einfach wahr und

die Landwirtschaftspolitik an der Grenze ist umgesetzt, damit die landwirt-

schaftliche Produktion der Schweiz angemessen geschützt ist.

Leistungsauftrag

Sicherheit + Migration Die Bevölkerung im Grenzraum fühlt sich sicher. Personen erfüllen die

Voraussetzungen für den Grenzübertritt in die Schweiz und in den Auf-

enthalt im Schengen-Raum.

Die Schweizer Wirtschaft ist als verlässlicher Partner einer sicheren Lo-

gistikkette anerkannt (AEO-Zertifizierung, Terrorbekämpfung). Fahrzeug-

lenkende halten sich und ihre Fahrzeuge in fahrtauglichem Zustand.

Leistungsauftrag



28/107


Umwelt + Gesundheit Umwelt und Bevölkerung sind davor geschützt, dass gesundheitsschädi-

gende, umweltgefährdende und/oder verbotene Produkte und Einflüsse

in die Schweiz gelangen. Tiere, Pflanzen und bedrohte Arten sind im

grenzüberschreitenden Verkehr ausreichend geschützt. Kunden und Wirt-

schaft ändern ihr Verhalten im Sinne der Zielsetzung von Lenkungsabga-

ben.

Leistungsauftrag

Aufgabenklarheit Die Leistungsbeschreibung/der Leistungsauftrag ist klar Strukturiert und

gibt Aufschluss über den Umfang und Inhalt der Geschäftstätigkeiten und

deren Anforderungen an das Fachwissen.

Interview

Wirtschaftlichkeit Ressourcen und Mittel werden zur optimalen Erfüllung des Leistungsauf-

trages eingesetzt.

Interview

Personal Die von der EZV unter den betrieblichen Gegebenheiten beeinflussbaren

Elemente der Personalstrategie 2011-2015 der Bundesverwaltung sind

umgesetzt. Die Aus- und Weiterbildung der EZV sichert die für die Aufga-

benerledigung notwendige Qualifikation der Mitarbeitenden und ent-

spricht den internationalen Standards (Bologna-Modell). Die Infrastruktur

für Aus- und Weiterbildung (Ausbildungszentrum Liestal, Kompetenzzent-

rum Sicherheit und Interventionstechnik Interlaken) entspricht den zu-

künftigen Erfordernissen an die Ausbildung des Personals.

Interview und

Leistungsauftrag

Führung Die Aufbauorganisation der OZD ist überprüft und angepasst; die Pro-

zesse und die Führungsstrukturen der gesamten EZV sind flexibel auf zu-

künftige Herausforderungen ausgerichtet. Die Eidg. Alkoholverwaltung ist

reibungslos in die EZV integriert; die Aufgaben zur Durchsetzung der Al-

koholpolitik und Alkoholmarktaufsicht werden effektiv und effizient erfüllt

und für die Steuerpflichtigen und den Handel durch eine optimal inte-

grierte Organisationseinheit wahrgenommen. Die IKT-Anwendungen im

Bereich Führung und Support stehen zeit- und anforderungsgerecht be-

reit. Mit dem integrierten Performance Management System ist die Steu-

erbarkeit der EZV erhöht und die Leistungserbringung transparent.

Leistungsauftrag

Digital Geschäftsrelevante Daten und Informationen sind elektronisch verfügbar. Interview

Mobil Geschäftsrelevante Daten und Informationen können ortsunabhängig be-

zogen werden. Benötigte Geräte und IT-Systeme sind ortsunabhängig

einsetzbar und transportabel.

Interview

Verfügbarkeit Geschäftsrelevante Daten und Informationen können jederzeit bezogen,

erfasst und verarbeitet werden.

Interview

Vertraulichkeit Sensitive Daten und Informationen sind gemäss bestehenden Bestim-

mungen vor unberechtigtem Zugriff gesichert und ein Zugriff ist nur für

berechtigte Personen möglich.

Interview

Identifizierbarkeit Einfache und personenbezogene Erkennung des Anwenders im IT-Sys-

tem sowie Zugriff auf die relevanten Funktionen und Daten.

Interview

Stabilität Jederzeit verfügbare Systemdienstleistungen, die Vertrauenswürdig und

fehlerfrei funktionieren.

Interview

Tabelle 3 Geschäftstreiberliste

Die erhobenen und validierten Treiber erlauben eine Ableitung der Bedürfnisse der Mitarbeitenden

(Erhebung Bottom-up) und den strategischen Vorgaben (Erhebung Top-down) auf die Ziele und



29/107

Rahmenbedingungen der SOLL-Architektur.

4.1.3 Geschäftsprinzipien

Auf der Grundlage der Geschäftstreiber und der im Kernteam GAR-EZV definierten Hypothesen wurden

die Geschäftsprinzipien EZV ausgearbeitet. Die Geschäftsprinzipien fassen die gewünschte Ausrichtung

der EZV zusammen und erlauben damit eine richtungsweisende Entscheidungsgrundlage für die ge-

samte EZV. Dabei sollen die Geschäftsprinzipien nicht einschränkend wirken. Sie bilden vielmehr Leit-

planken um die Entscheidungsfähigkeit zu erhöhen und den Nutzen für die gesamte EZV zu erhöhen.

Abbildung 13 zeigt die Zuweisung der erhobenen Treiber zum jeweiligen Geschäftsprinzip. Die Treiber

wurden in den Interviews und Workshops (Bottom-up) erhoben und aus dem Leistungsauftrag (Top-

down) abgeleitet.

Abbildung 13: Auflistung der Geschäftsprinzipien aufgrund der Geschäftstreiber

4.1.3.1 Struktur eines Geschäftsprinzips

Die Struktur eines Geschäftsprinzips ist in Abbildung 14 zusammengefasst. Ein Geschäftsprinzip soll da-

bei in kurzer Form die Kernaussage erkenntlich aufzeigen. Zudem sollen die wesentlichen Erkenntnisse

in Form der erhobenen Treiber sowie Rahmenbedingungen und Vorgaben beschrieben sein. Abschlies-

send werden die wichtigsten Auswirkungen auf die EZV zusammengefasst. Die Beschreibung der Aus-

sagen stützt sich dabei weitgehend auf die Chancen und Risiken aus den Interviews, welche assoziiert

mit den definierten Treibern sind. Die Konsequenzen sind ein Abgleich der Stärken und Schwächen mit

den in der Beschreibung summierten Chancen und Risiken. Dies ergibt ein verständliches und in sich

anwendbares Geschäftsprinzip.



30/107

Abbildung 14: Struktur eines Geschäftsprinzips

4.1.3.2 Anwendungen der Geschäftsprinzipien

Die konkrete Anwendung der Geschäftsprinzipien ist angedeutet durch die in Abbildung 15 dargestellten

Anwendungsgebiete. Diese stellen im Grunde die Abhängigkeiten der Prinzipien zueinander dar. Dabei

wird aus den acht definierten Prinzipien eine Matrix gebildet, welche die Prinzipien in die zwei Dimensio-

nen „Erfüllungsgrad“ und „Kerngeschäft“ aufteilt. Prinzipien in der Dimension „Erfüllungsgrad“ erklären in

diesem Sinne, wie die Aufgabe der EZV vollzogen werden soll und bilden die Verbindung zur Vision der

EZV. Demgegenüber erklären die Prinzipien in der Dimension „Kerngeschäft“ übergreifende Fähigkeiten

des Aufgabenvollzugs und stehen mit dem Leistungsauftrag in Verbindung.

Abbildung 15: Prinzipen-Matrix

Die Erarbeitung der Geschäftsfunktionen ermöglicht die konkrete Beschreibung der Abhängigkeiten

und erklärt somit die Anwendung der Prinzipien-Matrix im Detail.



31/107

4.1.3.3 Geschäftsprinzipien EZV

In diesem Unterkapitel sind die konsolidierten Geschäftsprinzipien in der definierten Struktur aufgeführt.

Die Abhängigkeiten der Prinzipien zueinander sind dabei im Moment noch nicht beschrieben, da diese

im Rahmen der Definition von Geschäftsfunktionen konkreter formuliert werden können.

In Abbildung 16 sind die Geschäftsprinzipien unstrukturiert dargestellt um die Essenz der acht Prinzipien

als einheitliche Aussage aufzuzeigen.

Abbildung 16: Übersicht Prinzipien EZV

Die Geschäftsprinzipien beschreiben die wünschenswerte Gestaltung des Aufgabenvollzugs der

EZV und erlauben die Geschäftsarchitektur ohne Betrachtung von Prozessen, der Organisation oder

von Funktionen zu beschreiben.



32/107

4.1.3.3.1 Integration

Geschäftsprinzip Integration

Nr. K.1

Titel Integration

Kurz-Beschreibung Die systematische Strukturierung und Vernetzung der Daten befähigt die EZV In-

formationen optimal einzusetzen und zu verwalten.

Beschreibung

Das Informationsmanagement steuert und regelt den Informations- resp. Datenfluss. Es werden nur Daten erhoben, welche für die effiziente Abwicklung der Geschäftspro-zesse sowie zur effektiven Erfüllung der Aufgaben erforderlich sind. Gleichartige Daten sollen nur in einem IT-System gepflegt und Umsystemen durch Ver-knüpfung zur Verfügung gestellt werden. Das setzt voraus, dass gleichartige Funktionen nur durch eine Applikation abgebildet werden.

Treiber

Interoperabilität

Durchgängigkeit

Konsistenz

Auswertbarkeit

Systemintegration

Rahmenbedingungen und Rechtsgrundlagen

Leistungsauftrag / Leistungsvereinbarung

Zielsetzung für die nächsten zwei Jahre

Zollgesetz / Zollverordnung (ZG / ZV) / Abgabenerlass

Datenschutzgesetz (DSG)

GEVER-Verordnung

e-Government Strategie Bund

Organisationsverordnung für das Eidgenössische Finanzdepartement

WZO Datenmodell

EU Datenmodell

EDV-Obligatorium

Selbstdeklarationsprinzip

Statistikabkommen

Impact / Auswirkungen

Die Erhebung der Daten muss harmonisiert werden (einheitliches Datenmodell). Um die Verknüpfung der Daten und Informationen zu ermöglichen müssen kombinierbare Da-tenstrukturen geschaffen werden. Die Datenlieferung (Anmeldungen) und -verwaltung (Kundenstammdaten) soll wenn im-mer möglich dem Kunden übertragen werden. Diese führt zu Aufwandreduktion seitens der EZV und zu höherer Flexibilität des Kunden da er zeitlich und räumlich unabhängig ist. Durch die klare Strukturierung der Daten werden unter anderem die für die EZV sehr wichtigen Auswertungen stark erleichtert.

Tabelle 4: Geschäftsprinzip Integration



33/107

4.1.3.3.2 Kooperation

Geschäftsprinzip Kooperation

Nr. K.2

Titel Kooperation

Kurz-Beschreibung Eine enge und zielgerichtete Zusammenarbeit mit internen und externen Partnern

erhöht die Leistungsfähigkeit und generiert Mehrwert.

Beschreibung

Die EZV ist stark vernetzt und kooperiert sowohl intern wie auch extern mit vielen unter-schiedlichen Partnern. Die interne Zusammenarbeit der verschiedenen Bereiche und Organisationseinheiten muss durch Datenverbindungen unterstützt werden. Das umfasst den Austausch und die gemeinsame Nutzung von Daten und Informationen. Erkenntnisse die innerhalb der Zoll-verwaltung gewonnen werden, müssen allen betroffenen Mitarbeitern zugänglich sein. Bei der externen Kooperation ist zwischen inländischen und ausländischen Partnern zu unterscheiden. Bei der Kooperation mit inländischen Partnern ist wichtig, dass die Zollbe-teiligten so einfach wie möglich, ohne grosse Auswirkungen auf die Geschäftsmodelle und die Lieferketten die benötigten Daten in der geforderten Qualität zum richtigen Zeit-punkt übermitteln können (Handelserleichterung). In der Kooperation mit inländischen Bundesbehörden ist die EZV in der Lage, die benötigten Daten zum richtigen Zeitpunkt auszutauschen. Zudem müssen die im Bereich der NZE (durch die EZV oder andere Bun-desämter) zu vollziehenden Aufgaben in die Geschäftsprozesse der EZV integriert wer-den können. Die Kooperation mit ausländischen Partnern wird mittels bilateraler oder multilateraler Ab-kommen verstärkt. Die Zusammenarbeit wird insbesondere durch automatischen Daten-austausch gefördert. Die EZV-Systeme müssen daher auch mit ausländischen Systemen Daten austauschen können.

Treiber

Vereinbarung

Kommunikation

Internationale Beteiligung

Nationale Zusammenarbeit


Zollgesetz und Zollverordnung (ZG/ZV) / Abgabenerlasse

Bundesgesetz über das Verwaltungsverfahren (VwVG)

Zolltarifgesetz

Allgemeines Präferenzsystem für Entwicklungsländer

Bundesgesetz über die Ein- und Ausfuhr von Erzeugnissen aus Landwirtschaftsprodukten „Schoggigesetz“

diverse nichtzollrechtliche Erlasse

Zollerleichterungs- und Zollsicherheitsabkommen (ZESA)

Übereinkommen über ein gemeinsames Versandverfahren (gVV)

WTO Trade Facilitation Agreement

diverse Amtshilfeabkommen & Freihandelsabkommen

TIR-Abkommen & Kimberly-Abkommen

diverse WZO-Konventionen und Abkommen (Kyoto, Istanbul, ATA etc.)

Abkommen über die gegenseitige Anerkennung des AEO-Status

Zollvertrag mit Liechtenstein, Deutschland (Büsingen)

"Zollkooperationsabkommen" mit den Nachbarstaaten

WZO SAFE Framework of Standards

WZO Datenmodell & EU Datenmodell

WZO Globally Networked Customs (GNC)

Polizeiabkommen (Internationale und nationale Vereinbarungen über die Zusammenarbeit im Polizeibereich)



34/107


Eine mit sämtlichen Partnern abgestimmte und koordinierte Kooperation erlaubt es Syner-gien zu nutzen und Doppelspurigkeiten zu eliminieren. Eine kohärente Zusammenarbeit bildet die Basis für die durchgehende Automatisierung von Prozessen. Zudem erlaubt sie, sich schneller an das ständig ändernde Umfeld anzupassen. Schliesslich lassen sich Ef-fektivitäts- und Effizienzgewinne realisieren, die es wiederum erlauben, die stetig steigen-den Anforderungen zu bewältigen. Als Basis für wirksame Zusammenarbeit müssen mit den Partnern gemeinsame Daten-austauschmöglichkeiten bestehen, die es allen beteiligten ermöglichen Daten bedarfsge-recht zu bearbeiten und gezielt und Adressatengerecht weiter zu geben.

Tabelle 5: Geschäftsprinzip Kooperation



35/107

4.1.3.3.3 Evolution

Geschäftsprinzip Evolution

Nr. K.3

Titel Evolution

Kurz-Beschreibung Die EZV passt sich vorausschauend und wirtschaftlich an die gestellten Anforde-

rungen und Veränderungen an.

Beschreibung

Die historisch gewachsenen Applikationen entsprechen heute den spezifischen Anfor-derungen einzelner Fachbereiche, jedoch nicht der gesamten EZV. Diese massge-schneiderten Lösungen sind jedoch ungenügend integriert und nicht erweiterbar oder wartbar. Um zukünftigen Anforderungen gerecht zu werden und die notwendige Flexibi-lität zur Erfüllung des heutigen sowie des nachfolgenden Leistungsauftrags zu gewähr-leisten, müssen die Arbeitsabläufe und IKT Mittel vereinfacht, modularisiert und harmo-nisiert werden. Dadurch wird eine effizientere Wartbarkeit sowie schnellere Skalierbar-keit erreicht und die EZV kann den Aufgabenvollzug auch zukünftig gewährleisten.

Treiber Flexibilität

Komplexität

Innovation




Zollgesetz / Zollverordnung (ZG / ZV) / Abgabenerlasse

Datenschutzgesetz (DSG) GEVER-Verordnung

e-Government Strategie Bund Organisationsverordnung für das Eidgenössische Finanzdepartement


Die Aufgaben der Zollverwaltung sowie der sich daraus ergebenden Geschäftsprozesse sind ständigen Anpassungen ausgesetzt. Die EZV muss Ihre Leistungsfähigkeit auch unter Berücksichtigung von sich ändernden Anforderungen gewähren können. Durch laufende Beobachtung und Evaluation von externen Faktoren unter Einbezug der relevanten Anspruchsgruppen muss sichergestellt werden, dass Veränderungen früh-zeitig identifiziert, analysiert und in Bezug auf deren Auswirkung evaluiert werden. Zur zeitnahen Umsetzung konkreter Massnahmen und Anpassungen müssen die IT-Lösun-gen den veränderten Geschäftsprozessen folgen können. Um die optimale Nutzung der Hilfsmittel in Zukunft zu gewährleisten, müssen die Mitar-beiter der EZV mit den Funktionen und Neuerungen vertraut gemacht und geschult wer-den

Tabelle 6: Geschäftsprinzip Evolution



36/107

4.1.3.3.4 IT-for-Business

Geschäftsprinzip IT-for-Business

Nr. K.4

Titel IT-for-Business

Kurz-Beschreibung Die IKT folgt den Geschäftsprozessen der EZV und unterstützt damit optimal die

Mitarbeiter und Kunden der EZV.

Beschreibung

Eines der wichtigsten Kriterien für eine Fachapplikation ist die Akzeptanz bei den Usern, sowohl interne als auch externe. Entscheidende Faktoren für eine solche positive Wahr-nehmung sind die Einfachheit, die Bedienbarkeit und der Unterstützungsaspekt. Die Applikation muss möglichst einfach aufgebaut sein und keine für die Geschäftsab-läufe unnötigen Funktionen haben. Durch die IKT soll der geregelte Geschäftsablauf vereinfacht oder beschleunigt werden. Im Grundsatz muss als erstes der Arbeitsablauf oder -prozess definiert werden, bevor der Einsatz der IKT spezifiziert werden kann. Die Evaluation von Anforderungen an IKT Mittel muss sich demnach zwingend an vorgängig optimierten Geschäftsprozessen ori-entieren.

Treiber

Steigerungsfähigkeit

Benutzerfreundlichkeit

Verständlichkeit

Systemverfügbarkeit

e-Gov




Zollgesetz / Zollverordnung (ZG / ZV) / Abgabenerlasse

Datenschutzgesetz (DSG) GEVER-Verordnung


Durch eine Anpassung der heute stark heterogenen und historisch gewachsenen IKT Landschaft an die harmonisierten Geschäftsprozesse können zukünftige Anforderungen erfüllt werden. Die Mitarbeiter erlangen dadurch mehr Zeit für ihre Aufgaben, welche menschliche Beteiligung erfordern. z.B. Interpretation der Daten und Führen der Teams (mit erhaltenen Infos) oder durchführen von Kontrollen. Um das Ziel einer homogenen IKT Landschaft zu erreichen, qualifizieren wir die Mitar-beiter so, dass die Akzeptanz gegeben ist. Intuitive Bedienung, starke Performance, zielorientierte Bearbeitung und hohe Vernet-zung sind die Grundpfeiler der anpassungsfähigen Anwendungen.

Tabelle 7: Geschäftsprinzip IT-for-Business



37/107

4.1.3.3.5 Zweckmässigkeit

Geschäftsprinzip Zweckmässigkeit

Nr. E.1

Titel Zweckmässigkeit

Kurz-Beschreibung Die EZV orientiert sich an den Anliegen von Bürgern, Partnern und Mitarbeitern um den Auftrag zukunftsorientiert mit dem kleinstmöglichen Aufwand zu erfül-len.

Beschreibung

Die Zollverwaltung hat mit seinen verschiedensten Aufgabengebieten eine Vielzahl von Bedürfnissen zu erfüllen. Dies widerspiegelt sich einerseits in den Anforderungen der Mitarbeiter an Funktionen, Auswertungen und Verfügbarkeiten, welche sie zur op-timalen Aufgabenerledigung benötigen. Anderseits in der unterschiedlichen Arten von Kunden und deren Wünschen und Möglichkeiten. Künftige Lösungen oder Anpassun-gen sind daher nicht als separate Herausforderung zu lösen (Insellösung) sondern im Gesamtkontext betrachtet werden, um einen optimale Einbettung sicherzustellen. Die IT muss die knapper werdenden personellen Ressourcen optimal unterstützen und Routineaufgaben abnehmen. Kunden sollen die verlangten Daten und Angaben möglichst einfach und schnell an die EZV liefern können, ohne ihre eigenen Abläufe zu stören.

Treiber

Öffentliche Anerkennung

Konformität

Nutzbarkeit

Strategie

Anforderungen

Einnahmen

Wirtschaft

Sicherheit + Migration

Umwelt + Gesundheit


Vision EZV


Kontrollstrategie Zoll

eGov Strategie Bund

Zollgesetz (ZG) / Abgabenerlasse

Zollverordnung (ZV)


diverse internationale Abkommen


Anforderungen von Mitarbeitenden, Kunden und Partnern müssen umfassend erho-ben und evaluiert werden. Die Evaluation bedingt eine Bewertung der Zweckmässig-keit resp. des dadurch generierten Nutzens. Die zukünftige Umsetzung des Aufgabenvollzugs orientiert sich an den Bedürfnissen der Mitarbeitenden, Partner und Kunden der EZV um die Wirkung zu optimieren.

Tabelle 8: Geschäftsprinzip Zweckmässigkeit



38/107

4.1.3.3.6 Leistungsfähigkeit

Geschäftsprinzip Leistungsfähigkeit

Nr. E.2

Titel Leistungsfähigkeit

Kurz-Beschreibung Die zur Verfügung stehenden Mittel und Ressourcen werden optimal auf die

Ziele der EZV ausgerichtet um das grösstmögliche Potenzial auszuschöpfen.

Beschreibung

Die Priorisierung von zukünftigen Investition folgt einem Aufwand / Nutzen-Prinzip. Dabei steht der Nutzen für die EZV, resp. die Gewährleistung der übertragenen Auf-gaben im Fokus. Die zur Verfügung stehenden beschränkten Mittel (personelle und finanzielle Ressourcen) werden so optimal auf die Unternehmensziele der EZV aus-gerichtet und dort eingesetzt, wo sie den höchsten Nutzen erzielen. Die EZV ist durch ihren Leistungsauftrag und die gesetzlichen Vorgaben in ihrer Handlung eingeschränkt. Die Leistungsfähigkeit ergibt sich aus der möglichst umfas-senden und ressourcenschonenden Umsetzung dieser Anforderungen. Die vereinfachte Anwendung von IKT-Mitteln erhöht die Produktivität bei gleichblei-bender Ressourcenverfügbarkeit. Weitere Chancen zur Steigerung der Leistungsfähigkeit ergeben sich durch den stär-keren Einbezug von Kunden und Partnern in die Wertschöpfungskette.

Treiber

Aufgabenklarheit

Wirtschaftlichkeit

Personal

Führung


Vision EZV


Kontrollstrategie Zoll

eGov Strategie Bund

Zollgesetz (ZG) / Abgabenerlasse

Zollverordnung (ZV)


diverse internationale Abkommen


Durch eine Vereinheitlichung von Datenmodellen und die Integration von Systemen könnten redundante Arbeitsschritte vermieden werden. Der möglichst frühe Einbezug von IKT-Kenntnissen in die Ausbildung, sowie mitarbeitergerechte Weiterbildungsan-gebote sind notwendig um die heutige, vor allem aber auch zukünftige Bedienbarkeit und damit die Leistungserbringung zu gewährleisten. Die Grundlagen zur transparenten Berechnung von Rentabilität mit Einschluss von Gesamtkosten von IKT-Gesamtkosten oder Produktivität mit Bezug zu Ressourcen-bedarf und Leistungserbringung müssen EZV-weit gegeben sein, um eine übergrei-fende Priorisierung von Investitionsbedarf vorzunehmen. Die Vereinheitlichung der bestehenden Landschaft kann dazu führen, dass effizient funktionierende Anwendungen angepasst werden müssen (z.B. an ein neues Daten-modell) und dadurch kurzfristig an Effizienz einbüssen. Die Komplexität der Systeme ist z.T. bereits heute beträchtlich. Eine weitere Komple-xitätszunahme kann zu einer schlechteren Wartung und zu Sicherheitsproblemen füh-ren. Risiken werden spät oder gar nicht erkannt. Die Abhängigkeit von Leistungser-bringern wird dadurch grösser.

Tabelle 9: Geschäftsprinzip Leistungsfähigkeit



39/107

4.1.3.3.7 Mobilität

Geschäftsprinzip Mobilität

Nr. E.3

Titel Mobilität

Kurz-Beschreibung Die EZV gestaltet ihre Geschäftsprozesse möglichst zeit- und ortsunabhängig um

ihre Aufgaben dezentral und anspruchsgerecht erbringen zu können.

Beschreibung

Die Mitarbeitenden kontrollieren Personen und Waren vermehrt ortsunabhängig. Des-halb benötigen sie Applikationen und Geräte, die ihre Arbeiten (Kontrolle, Rapportie-rung/Erfassung, Erledigung) vollumfänglich in ihrer Mobilität unterstützen. Rasche Ein-satzbereitschaft, gute Performance und umfassende Einsatzmöglichkeiten sind dabei kritische Faktoren. Die Ausprägung und die Bedürfnisse sind indes je nach Einsatzge-biet unterschiedlich und verändern sich laufend. Dazu müssen auch die notwendigen Informationen zu jeder Zeit und an jedem Ort verfügbar sein. Die Zollkunden wollen insbesondere im Reiseverkehr sowie im Handelswarenverkehr ebenfalls auf mobile Lösungen zurückgreifen, die ihre Reisetätigkeit aktiv erleichtert. Für beide Anspruchsgruppen ist die einmalige Datenerfassung und die vollkommen elektronische Geschäftsabwicklung (papierlos) ein klares Ziel. Die Effizienz der Arbeit soll so signifikant erhöht werden.

Treiber Digital

Mobil

Verfügbarkeit


Verordnung über die Informatik und Telekommunikation in der Bundesverwaltung (Bundes-informatikverordnung, BinfV)

Verordnung über die Personensicherheitsprüfungen (PSPV)

Verordnung über den Schutz von Personendaten des Bundespersonals (BPDV)

Verordnung über die Bearbeitung von Personendaten in der Eidgenössischen Zollverwal-tung (Datenbearbeitungsverordnung für die EZV)

Weisung über die Informatik und Telekommunikation im Eidgenössischen Finanzdeparte-ment (WIT-EFD)

Weisung für die Benutzung von Informatikmitteln im Eidgenössischen Finanzdepartement (WIM-EFD)

Strategie mobiles Arbeiten EZV (In Arbeit)

Teilstrategie mobiles Arbeiten (ISB)


Zukunftsgerichtete Lösungen müssen als Basis eine hohe Funktionalität für die mobilen Mitarbeitenden und Zollkunden anbieten. Die EZV stellt heute diesbezüglich ein unge-nügendes Angebot für Mitarbeitende und Zollkunden zur Verfügung. Die mobil ausge-führten Aufgaben werden stets ausgebaut. Dabei werden auch (mobile) Einsätze im Ausland an Bedeutung gewinnen. Immer stärker verwässert sich die Trennung zwi-schen Arbeit und Freizeit. Dies äussert sich darin, dass Mitarbeitende sich auf ihren mo-bilen Geräten auf die kommende Geschäftstätigkeit vorbereiten (Einsatzpläne, aktuelle Erkenntnisse und Trends, etc.) und auch der Dienstabschluss fliessend in die Freizeit übergeht (Zeit- / Spesenerfassung, Mail, etc.). Arbeitstätigkeiten erfolgen teilweise an fixen Arbeitsplätzen, zu wesentlichen Teilen aber auch mobil. Alle Funktionalitäten müssen weitgehend plattform- / geräte- und standortunabhängig einsetzbar sein. Auch ausserhalb der Arbeitszeit. Die Bedienung muss schnell, einfach und intuitiv sein. Dabei müssen nur die zur Aufgabenerfüllung notwendigen Informatio-nen zur Verfügung stehen. Der User bestimmt individuell mit, mit welchen Hilfsmitteln er effizient arbeitet. Geschäftsprozesse müssen sukzessive papierlos angeboten und vereinfacht werden, um diese zeitlich aber vor allem örtlich unabhängig zu gestalten. Die Geschäftsstandorte müssen die mobilen Arbeitshilfsmittel optimal ergänzen (Peri-pherie, Konnektivität, etc.) Die Mobilität eröffnet neue Möglichkeiten und erfordert eine umfassende Analyse der heutigen Geschäftsprozesse in Bezug auf die Zeit- und Ortsunabhängigkeit.

Tabelle 10: Geschäftsprinzip Mobilität



40/107

4.1.3.3.8 Informationssicherheit

Geschäftsprinzip Informationssicherheit

Nr. E.4

Titel Informationssicherheit

Kurz-Beschreibung Die EZV steht für integrale Sicherheit ein und gewährleistet insbesondere die Ver-

traulichkeit, Integrität, und Verfügbarkeit der Informationen.

Beschreibung

Die integrale Sicherheit bildet den Rahmen für die Aufgabenwahrnehmung der EZV und umfasst nebst dem Informationsschutz ebenfalls den Arbeitsschutz, Gesundheitsschutz, etc. Aktuelle, korrekte und jederzeit verfügbare Informationen sind unabdingbare Vorausset-zungen, um die Aufgaben gemäss den Anforderungen der verschiedenen Anspruchsgrup-pen erfüllen zu können. Die EZV setzt darum alle erforderlichen und wirtschaftlich vertret-baren technischen und organisatorischen Sicherheitsmassnahmen zur Sicherstellung von Vertraulichkeit, Integrität, Verfügbarkeit und Nachvollziehbarkeit dieser Informationen um. Der angemessene Aufwand der Sicherheit ergibt sich aus dem Schutzbedarf der Informati-onen und den Gefährdungen, denen sie ausgesetzt sind, sowie durch die technischen und organisatorischen Mittel, die dafür eingesetzt werden. Durch eine hohe Sicherheit der Informationen werden die Geschäftsprozesse unterstützt (Verfügbarkeit, Integrität) und die die EZV hat eine gute Reputation (Vertraulichkeit) gegen aussen.

Treiber Vertraulichkeit

Identifizierbarkeit

Stabilität


Regierungs- und Verwaltungsorganisationsgesetz ( RVOG)

Bundesgesetz über den Datenschutz (DSG)

Bundesgesetz über das Verwaltungsverfahren (Verwaltungsverfahrensgesetz VwVG)

Verordnung zum Bundesgesetz über den Datenschutz (VDSG)

Regierungs- und Verwaltungsorganisationsverordnung (RVOV)

Verordnung über den Schutz von Informationen des Bundes (Informationsschutzverordnung, ISchV)

Verordnung über die Informatik und Telekommunikation in der Bundesverwaltung (Bundesin-formatikverordnung, BinfV)

Verordnung über die Personensicherheitsprüfungen (PSPV)

Verordnung über den Schutz von Personendaten des Bundespersonals (BPDV)

Verordnung über die Bearbeitung von Personendaten in der Eidgenössischen Zollverwaltung (Datenbearbeitungsverordnung für die EZV)

Verordnung über die Bearbeitung von Personendaten, die bei der Nutzung der elektronischen Infrastruktur des Bundes anfallen (Randdatenverordnung)

Weisungen über die Informatiksicherheit in der Bundesverwaltung WIsB

Weisung über die Informatik und Telekommunikation im Eidgenössischen Finanzdepartement (WIT-EFD)

Weisung für die Benutzung von Informatikmitteln im Eidgenössischen Finanzdepartement (WIM-EFD)

Weisung über die Referenzarchitektur für Fachanwendungen im Eidgenössischen Finanzde-partement (inkl. Anhang)


Die Verfügbarkeit der Informationen entspricht heute grundsätzlich den Ansprüchen der Aufgabenträger. Einschränkungen bestehen bei der Zugriffsgeschwindigkeit und bei der Komplexität der Informationssysteme. Massnahmen zur Sicherstellung der Informationssicherheit (Passwörter, Authentifizierung, Standardisierung) werden teilweise als Schwäche oder Risiko empfunden. Die systematische Erarbeitung eines ISMS (Informationsschutz Management Systems) wird die Sicherheit nachhaltig und kontinuierlich erhöht. Die Sicherheit ist heute nicht flächendeckend gewährleistet und sie ist nicht auf dem heute erforderlichen Stand. Die Risiken sind nicht umfassend bekannt und nicht systematisch er-fasst. Durch den Aufbau des ISMS unter betriebswirtschaftlichen Aspekten kann systema-tisch und der Geschäftsanforderungen eine den Anforderungen angepasste Sicherheit er-reicht werden. Nicht anforderungsgerechte Massnahmen zur Aufrechterhaltung der Si-cherheit führen zu einer Einschränkung der Wirtschaftlichkeit der Geschäftsprozesse.

Tabelle 11: Geschäftsprinzip Informationssicherheit



41/107

4.1.4 Geschäftsfunktionen

Die Geschäftsfunktionen bilden die Basis für die zu definierende SOLL-Architektur. Aus den erhobenen

Bedürfnissen aus den Interviews, sowie den Vorarbeiten aus Redesign Fracht und VSP, wurden die be-

nötigten Geschäftsfunktionen abgeleitet.

Diese beschreiben die geschäftlichen Tätigkeiten der EZV, welche zur Erfüllung ihrer Aufgaben benötigt

werden. Die nachfolgende Tabelle beschreibt die IST-Geschäftsfunktionen:

Geschäftsfunktion Beschreibung

Personenverkehr

Situation feststellen

Die Situation wird durch den Grenzwächter anhand von physischen Merkmalen wie (Fahrzeug-

herkunft, Anzahl Insassen, Gesichtsform der Insassen, Herkunft der Insassen, Zustand des

Fahrzeuges (z.B. Überladen), Alarmsignale AFV, etc. erfasst.

Personen identifizieren

Die Person und das Fahrzeug werden identifiziert, indem die notwendigen Dokumente verlangt

und eingesehen werden (Pass, Führerschein, Fahrzeugschein, etc.) und danach das Foto mit

der Person, resp. die Daten mit dem Fahrzeug verglichen werden. Ebenfalls werden Merkmale

wie Sprache, Namen, etc. auf Unstimmigkeiten analysiert. Bei Unstimmigkeiten oder fehlenden

Informationsgrundlagen (Ausländer) wird die Identifikation ausgedehnt auf Fingerabdruckanalyse

(AFIS) und/oder Anfragen bei in- und ausländischen Behörden.

Personen prüfen

Die Prüfung erfolgt durch Analyse der Dokumente in erster Linie (Echtheit der Dokumente zuerst

visuell dann mittels Geräten) sowie das Abklären der Einreisevoraussetzungen (Visum, Gültigkeit

der Dokumente, etc.). Aus Sicherheitsgründen wird bei einer Zollkontrolle jede Person / Fahr-

zeug ebenfalls noch mit den Fahndungssystemen (eneXs, RIPOL-B) und Rapportierungssyste-

men, etc. abgeglichen.

Massnahme festlegen

Je nach Situation werden die entsprechenden Massnahmen (z.B. Festnahme, Festhalten,

Busse, Kaution, AFIS-Speicherung, etc.) festgelegt. Die Massnahme wird rapportiert (z.B. RI-

POL-B, Rapportierung, Wordvorlagen bei Strafprotokollen) und gegebenenfalls werden weitere

Untersuchungen eingeleitet (z.B. Fahrzeugrevisionen, körperliche Durchsuchungen, zusätzliche

Daten erfassen, etc.).

Massnahme durchsetzen

Aufgrund der festgelegten Massnahme werden diese umgesetzt (z.B. Bussen und Kaution erhe-

ben, Festnahme durchführen, Person zurückweisen, Personen an andere Stellen überführen,

etc.). Dies kann auch mittels Zwangsmassnahmen (z.B. Einsatz von Handschellen, Schusswaffe,

Pfefferspray, Schutzhund, etc.) erfolgen.

Verfahren und Geschäftsdossiers ver-

walten

Revisions- und gerichtstaugliche Führung des Dossier sowie verwalten von Status innerhalb des

Verfahren.

Dienstleistungen erbringen und faktu-

rieren

Dienstleistungen für Kunden (z.B. Auskünfte erteilen, Notpässe ausstellen, Vignetten verkaufen,

Visa ausstellen, etc.). Für interne / externe Partner (z.B. Fahrzeugrevisionen, Abklärungen über

Grenzübertitte von Personen und Fahrzeugen, etc.) werden erbracht und fakturiert.

Informationen verwalten Nachvollziehbarkeit und Einsicht in die Verfahren und Geschäftsfalldossier ermöglichen um Infor-

mationen zu ergänzen oder abzurufen.

Warenverkehr

Anmeldung erfassen

Beinhaltet sämtliche Anmeldungen und Vorausanmeldungen im Warenverkehr der Zollbeteilig-

ten. Die Anmeldungen und Vorausanmeldungen können korrigiert, gelöscht oder erweitert wer-

den.

Anmeldung kontrollieren Umfasst plausibilisieren, selektionieren, bearbeiten und annehmen von normalen Anmeldungen

und mehrstufigen Verfahren.

Anmeldung bearbeiten Darunter fallen bearbeiten von vorhandenen Anmeldungen bei mehrstufigen Verfahren vom Mit-

arbeiter EZV oder Zollbeteiligten

Anmeldung formell & Ware materiell

kontrollieren

Anmeldung und Ware mit entsprechender Selektion formell und evtl. materiell kontrollieren inkl.

allfälliger Laboranalysen.



42/107


Ware verwalten Waren können in ein Lager ein- bzw. ausgelagert werden. Zudem umfasst diese Funktion die

Beschlagnahmung von Waren.


walten

Revisionstaugliche Führung des Dossier und führen von Status innerhalb des Verfahren.

Abgaben festlegen

Abgaben, Rückerstattungen und Entlastungen festlegen. Abgaben aufgrund der erfolgreich an-

genommen Anmeldung provisorisch oder definitiv festsetzen. Als Berechnungsgrundlage dienen

die eingereichten, plausibilisierten und angenommenen Daten aus allen Verfahrensbereichen.



Abgaben

Anmeldung erfassen Mit Anmeldung ermöglicht es dem Benutzer (intern oder extern) die Anmeldungen im Bereich

Abgaben. Die Anmeldungen können korrigiert, gelöscht oder erweitert werden

Anmeldung kontrollieren Beinhaltet die Plausibilisierung, die Selektion und die Annahme von Anmeldungen.

Anmeldung bearbeiten Besteht aus der Bearbeitung bei mehrstufigen Verfahren.

Anmeldung formell & Ware materiell

kontrollieren

Anmeldung und Ware mit entsprechender Selektion formell und evtl. materiell kontrollieren inkl.

allfälliger Laboranalysen.

Ware verwalten

Waren können in ein Lager ein- bzw. ausgelagert werden. Zudem umfasst diese Funktion die

Beschlagnahmung von Waren. Zudem muss pro Kunde eine Warenbuchhaltung geführt werden

können.


walten

Revisionstaugliche Führung des Dossier und führen von Status innerhalb des Verfahren.

Abgaben festlegen Abgaben, Rückerstattungen und Entlastungen festlegen. Als Berechnungsgrundlage dienen die

eingereichten, plausibilisierten und angenommenen Daten aus allen Verfahrensbereichen.



Edelmetallkontrolle und Qualitätssi-

cherung

Die Edelmetallkontrolle regelt den Handel mit Waren aus Edelmetallen und überzogene Waren.


Finanzmanagement

Abgaben und Bussen erheben und si-

cherstellen sowie Rückerstattung und

Entlastung leisten

Beinhaltet das Inkasso sowie die Rückerstattungen und Entlastungen auf Sicherheiten.

Controlling

Mit dem Controlling auf der operativen Ebene werden die Wirtschaftlichkeit, die Ziele und Res-

sourcen von Lösungen während der ganzen Lebensdauer verfolgt und dokumentiert.

Zahlung einfordern Beinhaltet die Rechnungsstellung und das Mahnwesen.

Bürgschaften / Sicherheiten verwalten Führen der Bürgschaften und Sicherheiten nach den verschiedenen Geschäftsfällen

Buchhaltung führen Führen der Buchhaltung der EZV inkl. sämtlicher Finanzaspekte.

Kontrolle interne Finanzflüsse und

Prozesse (IKS)

Sicherstellen des IKS Prozess.

Geschäftsdatenmanagement

Kundenverwaltung Erfassung, Bewertung und Pflege sämtlicher Kundendaten von Zollbeteiligten

Stammdatenverwaltung Pflege der Stammdaten sämtlicher Geschäftstätigkeiten der EZV

Dokumentenverwaltung Zentrale Dokumentenverwaltung mittels DMS.



43/107


Bewilligungen und Kontingente ver-

walten

Unter anderem für die Überführung resp. Lagerung von Waren in gewisse Verfahren wird ein Be-

willigung oder Kontingent benötigt.

Geschäftsverwaltung Setzt die GEVER Vorgaben als minimal Standard um.

Datenaustausch

Alle Zollbeteiligten und Partner (EU, andere Ämter, etc.) welche mit der EZV elektronisch Daten

austauschen, werden über den Service Daten austauschen integriert. Meldungen können emp-

fangen, abgeholt und versendet werden.

Recht und Untersuchung

Beschwerden verwalten und behan-

deln

Beinhaltet Verfügungen inkl. rechtlichem Prozess (rechtliches Gehör, usw.)

Vorermittlungen durchführen

Unter Vorermittlungen sind zollpolizeiliche Massnahmen und Abklärungen zu verstehen, welche

auf die Verdachtsbegründung gerichtet sind oder aber auf kriminalistischen Erfahrungswerten

gründen können, welche noch nicht für die Einleitung einer Strafuntersuchung gestützt auf Art.

37 VStrR genügen.

Strafverfahren verwalten und behan-

deln

Beinhaltet das Rapportieren und Anzeigen erstellen, sowie das Eröffnen und Durchführen von

Strafverfahren und Strafentscheide erstellen.

Amts- und Rechtshilfe leisten und er-

suchen

Beinhaltet Amts- und Rechtshilfe mit dem Ausland sowie Amtshilfe mit nationalen Behörden.

Internationale Abkommen verhandeln,

ausarbeiten und nachtragen

Teilnahme an Sitzungen, Konferenzen und Verhandlungsrunden im In- und Ausland, um Abkom-

men ausarbeiten.

Rechtliche Grundlagen anpassen/er-

stellen

Neue Rechtsgrundlagen (formelles Gesetz, Verordnungen des Bundesrates, Departementes o-

der des Amtes) erarbeiten bzw. bestehende Rechtsgrundlagen an neue Anforderungen anpas-

sen. Der Anstoss für die Schaffung kann entweder vom Parlament, dem Bundesrat oder auch

von der Behörde selbst erfolgen.

Administrative Massnahmen einleiten

z.B. Mit der Anwendung der vereinfachten Verfahren ZVE und des Zolllagerverfahrens OZL ge-

hen Rechte und Verpflichtungen auf den Bewilligungsinhaber über. Erfüllt ein Bewilligungsinha-

ber die Anforderungen der EZV nicht in genügendem Masse, können gegen ihn Administrativ-

massnahmen bis hin zum Bewilligungsentzug verfügt werden.

Vernehmlassung behandeln (Stellung-

nahme zu Gerichtsfällen abgeben)

Ausarbeitung von Vernehmlassungen zu Beschwerden gegen Entscheide der EZV an Gerichte

(Bundesverwaltungs-, Bundesstraf- und Bundesgericht)

Erlassensentscheid fällen Beurteilung von Erlassgesuchen und Ausarbeiten von Erlassentscheiden gestützt auf die gesetz-

lichen Bestimmungen und die Rechtsprechung.

Ressourcen-Management

Mitarbeitende EZV ausbilden und ent-

wickeln*

Beinhaltet die Aus- und Weiterbildung aller Personal- und Hierarchiekategorien.

Inventar führen*8

Das Inventar ist eine detaillierte Liste von Entitäten, um die Bewertung oder die Verwaltung zu

erleichtern. "Inventar führen" besteht aus der Bestandsaufnahme eines Lagerinhaltes, welche

(mindestens jährlich) regelmässig ausgeführt wird, um zu überprüfen, ob am Bilanzstichtag der

Lagerwert mit dem Bestand übereinstimmt.

Immobilien bewirtschaften*

Beinhaltet das Bewirtschaften der Stammdaten, der Dienstwohnungen, der Betriebsgebäude

inkl. dem Flächenmanagement, Objektmanagement und dem allgemeinen Reporting aller EZV-

eigenen Immobilien und Mietobjekten

Material und Fahrzeuge bewirtschaf-

ten*

Beinhaltet die Material und Fahrzeugprozesse für Instandhaltung

Einsatz von Personal und Material /

Fahrzeuge planen

Beinhaltet die Planung von Material und Fahrzeugen (Logistisch, Einsatz und Ersatz)

8 * Auf diese Funktion wird im Rahmen von GAR-EZV nicht weiter eingegangen. Wie in Dokument A (IST-Architektur) abgegrenzt, sind Füh-

rungs- und Supportprozesse nicht Teil des analysierten Umfangs.



44/107


Personalplanung* Personalbedarf der EZV inkl. Prognosen abgeleitet vom Leistungsauftrag

Strategische IKT Planung und Portfo-lio Bewirtschaftung*

IKT-Portfolio und IKT-Budget führen. IKT-Planung und

IKT-Portfolio werden periodisch von der jeweils zuständigen Geschäftsleitung verabschiedet.

Geschäftsanalyse & Reporting

Standardisierte Auswertungen (Re-

ports) anwenden und ad-hoc Abfragen

ermöglichen

Anzahl und Aufwand für individuelle Ad hoc Abfragen von BO PowerUser mittels vorgefertigten

Standard Reports reduzieren und diese zentral und wiederverwendbar zur Verfügung stellen.

Vom CCBI werden die fachlichen Anforderungen für ein klares Set von BO Reports beschrieben

– und den Benutzerkreis zur Durchsicht unterbreitet. Die Vorstellungen werden konsolidiert, be-

schrieben und zeitnah umgesetzt

Daten mittels Werkzeug in eine Abfrage können frei selektiert und auswertet werden. Die Ab-

frage kann für Wiederverwendung gespeichert werden (Ad-hoc Abfragen)

Externe und interne Statistiken erstel-

len

Die internen und externen Statistiken stellen den interessierten Kreisen – Wirtschaft, Wissen-

schaft und Verwaltung, aber auch Privatpersonen – Daten und statistische Unterlagen über die

laufende Entwicklung des Aussenhandels für wirtschaftliche Entscheidungen und zur Meinungs-

bildung bereit.

Zentrale Selektion festlegen

Mit der zentralen Selektionsmöglichkeit kann die Sektion Risikoanalyse in stark risikobehafteten

Situationen in der ganzen EZV oder in Teilbereichen eine unverzügliche und einheitliche Inter-

vention vornehmen.

Kunden und Partner bewerten Zollbeteiligte können verglichen werden und es können mittels einer Bewertung Aussagen über

die Dringlichkeit von Zollkontrollen gemacht werden

Risikoanalysen durchführen und Risi-

kobewertung, Risikoprofil, Lagebild,

etc. bereitstellen

Grundlage für die Durchführung von Risikoanalysen sind Hinweise und/oder Feststellungen,

Kundenbewertungen, Informationen der Zollstellen, der Kreisdirektionen, der Fachdienste OZD

aber auch von anderen Bundesämtern sowie eigene Feststellungen über Verkehrsverlagerun-

gen, Trends, Modi operandi, spezielle Vorkommnisse etc. Bei der Durchführung einer Risikoana-

lyse ist auf eine themenübergreifende (Vernetzung der Risiken) Analyse zu achten.

Der Ablauf einer Risikoanalyse ist ein Sammlung von Informationen, systematische Auswertung,

gezielte Aufbereitung /Analyse und am Schluss Risikoprofilen, Lagebild zu erstellen

Tabelle 12: Beschreibung Geschäftsfunktionen

Die heutigen Funktionen werden mit neuen, künftig benötigten Geschäftseigenschaften ergänzt.

Die SOLL-Geschäftseigenschaften beschreiben Erweiterungen bzw. Anpassungen der heutigen Ge-

schäftsfunktionen. Durch Erreichen dieser Eigenschaften kann die Erfüllung von Geschäftsfunktionen

verbessert oder die Befriedigung von neuen Bedürfnissen abgedeckt werden.



45/107

Die Eigenschaften wurden auf der Basis der Treiber, den Bedürfnissen aus Interviews und Workshops

sowie der Ableitung der IST-Funktionen definiert. Es handelt sich eher um eine abstrakte Darstellung

und weniger um eine exakte Definition von SOLL-Geschäftsfunktionen im Rahmen des Aufgabenvollzu-

ges der EZV.

SOLL-Geschäftseigenschaften

Personenverkehr

Anforderungsgerechte Weiterbildungsmöglichkeiten

Anforderungsgerechtes Portfoliomanagement

Automatische Nachvollziehbarkeit

Automatisierte Geschäftsabläufe

Digitale Kommunikation

Durchgängige Informationsbewirtschaftung

Durchgängige Suchfunktion

Echtzeit Informationsaustausch

Echtzeit Kommunikation

Einfache Authentifizierung

Einheitliche Benutzeroberfläche

Einmalige Authentifizierung

Elektronische Geschäftsverwaltung

Elektronischer Informationsaustausch

Flexible Ressourcenbewirtschaftung

Individuelle Ressourcenbewirtschaftung

Informationsgestützte Führung

Intuitive Geschäftsabwicklung

Konformes Dienstleistungsangebot

Langfristige IKT-Strategie

Mobile Auswertung

Mobile Informationsbewirtschaftung

Ressourcenunabhängigkeit

Sichere Informationsverwaltung

Sicherer Informationsaustausch

Umfassende Informationsverfügbarkeit

Vereinfachte Informationsverwaltung

Zeitunabhängige Informationsbewirtschaftung

Zentrale Informationsbewirtschaftung

Zugriff auf Partnersysteme

Zukunftsfähiges IT-System

Warenverkehr





Durchgängige Prozesse







Elektronische Selbstdeklaration

Fachliche Weiterbildung

Funktionalitäten konsolidieren

Gemeinsame Geschäftsverwaltung




Kooperative Ausführung von Aufträgen


Rollenbasierter Informationszugriff

Sichere Informationsverwaltung

Sicherer Informationsaustausch

Transparente Geschäftsabwicklung

Transparentes Portfoliomanagement


Umfassender Informationszugriff

Vertrauliche Informationsverwaltung




Abgaben

Anforderungsgerechte IKT-System








Echtzeit Plausibilisierung

Effiziente Geschäftsabwicklung


Fachliche Weiterbildung


Hohe Servicequalität gegenüber Kunden





Langfristige IKT-Strategie


Modularer Ressourceneinsatz

Nachvollziehbare Geschäftsverwaltung



46/107

SOLL-Geschäftseigenschaften


Einheitliche Informationsauswertung





Ressourcenunabhängigkeit


Systemgeführte Geschäftsabwicklung





Finanzmanagement

Automatischer Informationsaustausch



Effiziente Gebührenverrechnung




Elektronische Verrechnungsmodelle



Schnelle Anforderungsumsetzung


Transparente Geschäftsabwicklung

Transparente Kostenverrechnung


Vertrauliche Informationsverwaltung

Zentrale Informationsbearbeitung


Geschäftsdatenmanagement

Anforderungsgerechtes Portfoliomanagement


Durchgängige Informationsauswertung


Effiziente Anforderungsumsetzung





Gemeinsame Geschäftsverwaltung


Konsistente Informationsbewirtschaftung


Umfassender Informationszugriff




Recht und Untersuchung








Einheitliche Geschäftsabläufe


Einheitliche Informationsbewirtschaftung




Kooperative Ausführung von Aufträgen


Qualitätsmanagement

Schnelle Anforderungsumsetzung




Ressourcen-Management









Geschäftsorientiertes IKT-Management



Integrale Risikoanalyse

Integrale Sicherheit



Modularer Ressourceneinsatz

Sichere Geschäftsabwicklung




47/107

Geschäftsanalyse & Reporting




Einheitliche Geschäftsabläufe



Integrale Risikoanalyse



Zentrale Informationsauswertung


Tabelle 13: Beschreibung SOLL-Geschäftseigenschaften

4.1.4.1 Geschäftsfunktionsmap

4.1.4.1.1 IST-Geschäftsfunktions-Heat-Map

Als Vorbereitung für die GAP-Analyse wird eine IST-Geschäftsfunktions-Heat-Map erstellt. Aus dieser ist

ersichtlich, welche fachlichen Funktionen heute nicht oder nicht genügend erfüllt werden können.

Dabei wird unterschieden, wie stark der bestehende Handlungsbedarf ist.



48/107

Abbildung 17: IST-Geschäftsfunktions-Heat-Map

4.1.4.1.2 SOLL-Geschäftseigenschafts-Map

Die nachfolgende Abbildung zeigt, wie die kritischen und optimierbaren Felder durch die Geschäftsei-

genschaften entschärft werden können. Durch die untenstehende Grafik, wird der angestrebte SOLL-

Zustand dargestellt. Dieser Zustand wiederspiegelt die Bedürfnisse, welche die Mitarbeiter für die opti-

male Aufgabenerledigung geäussert haben.

Die ausgegrauten Felder zeigen den unkritischen Bereich der IST-Geschäftsfunktions-Map, für welchen

kein unmittelbarer Handlungsbedarf beschrieben wurde.



49/107

Abbildung 18: SOLL-Geschäftseigenschafts-Map



50/107

4.1.4.2 Geschäftsfunktionsmodell

4.1.4.2.1 IST-Modell

Das Geschäftsfunktionsmodell stellt die Geschäftsfunktionen im operativen Modell der EZV dar.

In dieser Darstellung werden nur die heutigen Funktionen dargestellt. Diese sind den Geschäftsfeldern

zugeordnet (vgl. auch Kapitel 4.1.1)

Abbildung 19: IST-Geschäftsfunktionsmodell

4.1.4.2.2 SOLL-Modell

Das Geschäftsfunktionsmodell der EZV zeigt, wie die beschriebenen Geschäftsfelder in das operative

SOLL-Modell integriert werden. Die Geschäftsfelder werden dabei durch die Bereiche Zentraler Zugang,

Integration & Prozesssteuerung, IT-Sicherheit sowie Basisdienste ergänzt. Komplettiert wird das Modell

durch die Bereiche Führung & Unterstützung sowie nationale, internationale Partner und innere Sicher-

heit, welche allerdings nicht im Fokus von GAR-EZV stehen und deshalb hier nicht näher beschrieben

werden. Die Beschreibung der Zusammenarbeit mit Partnern ist der Kapitel 4.3 der IST-Architektur

[GAR-ISTARCH]zu entnehmen.



51/107

Abbildung 20: IST-Geschäftsfunktionsmodell ergänzt mit SOLL-Geschäftseigenschaften



52/107

Nachfolgend sind die zusätzlichen Elemente des SOLL-Geschäftsfunktionsmodell beschrieben:

Zentraler Zugang

Für den Austausch von Daten und Informationen soll ein zentraler Zugang aufgebaut werden. Dieser de-

finierte Zugang gilt als einheitlicher Kommunikationskanal für Kunden, Partner und Mitarbeitende der

EZV, übergreifend für alle Bereiche der EZV. Dies schliesst EZV-interne soweit EZV-externe Anwender

mit ein.

Ein in diesem Kontext oft genanntes Konzept ist das Single Window-Konzept, welches diesen Zugang

sowie die Vorteile daraus beschreibt. Für den Bereich Warenverkehr Grenze beschreibt die Wirtschafts-

kommission für Europa der Vereinten Nationen dieses Konzept sinngemäss als „ein System, dass dem

Kunden erlaubt, alle für den Import oder Export nötigen Informationen an einen zentralen Punkt zu über-

mitteln“9.

Integration und Prozesse

Unter Integration wird in diesem Zusammenhang die durchgängige, unternehmensweite Verknüpfung

der einzelnen Anwendungen und Informationen verstanden. Diese EZV-weiten Informationsflüsse er-

möglichen die Abbildung und Steuerung von Prozessen sowie die Auswertungen und Suchmöglichkeiten

über verschiedenen Anwendungen hinaus.

Sicherheit

Der Bereich beinhaltet alle Funktionen zur unternehmensweiten Durchsetzung von Sicherheitsvorgaben.

Zum Beispiel werden die Benutzer- und Zugriffsrechte oder elektronische Schlüssel vergeben, überprüft

und verwaltet.

Basisdienste

Unter Basisdienste werden aufgabenunabhängige Funktionen verstanden, welche z.B. für den grundle-

genden Informationsaustausch (Telefon, UCC, usw.) benötigt werden. Dabei handelt es sich typischer-

weise um Funktionen, welche amtsübergreifend, wie zum Beispiel mit der Referenz-Architektur GS EFD,

angeglichen werden können.

9 Quelle: http://www.unece.org/fileadmin/DAM/trade/ctied/ctied7/ece_trade_324e.pdf | 31.07.2015, 09:42 Uhr



53/107

4.1.4.3 Geschäftsfunktionsmatrix

Die folgende Matrix zeigt die Abhängigkeiten der einzelnen Geschäftsprinzipien. Die Überschneidungen

des jeweiligen Kerngeschäfts-Prinzip mit einem Erfüllungsgrad-Prinzip zeigt die gegenseitige Beeinflus-

sung.

Um die Abhängigkeit besser zu verstehen, können die Geschäftsprinzipien in zwei Gruppen eingeteilt

werden (vgl. Kapitel 4.1.3):

Hauptaufgaben oder WAS soll erreicht werden?

und

Erfüllungsgrad oder WIE soll es erreicht werden?

Abgeleitet vom Zweck ist in untenstehender Tabelle pro Prinzip eine steuernde Grundsatzfrage abgelei-

tet. Diese Frage ermöglicht die Interpretation von Abbildung 21 und unterstützt die EZV-weite, homo-

gene Ausrichtung der IKT.

Prinzip Zweck Frage

Hau

pta

ufg

ab

e

Integration Einheitliche, zentrale und durchgän-

gige Informationsverwaltung und -

auswertung.

Was stellt die Tätigkeit der EZV si-

cher?

Kooperation Partner- und Kundenübergreifende

elektronische Informationsbewirt-

schaftung.

Was macht die EZV in Zusammenar-

beit mit Partnern und Kunden?

Evolution Rasche, effiziente und zukunftsge-

richtete Umsetzung von Anforderun-

gen und Erweiterungen.

Was sind zukünftige Veränderungen?

IT-for-Business Benutzerzentrierte, stabile und be-

darfsgerechte Anwendungen und

Services.

Was braucht die EZV zur Unterstüt-

zung?

Erf

üll

un

gs

gra

d

Zweckmässigkeit Optimum an Wirkung durch langfristig

ausgerichtete Kunden- und Partner-

anforderungen.

Wie stellt die EZV Qualität und Kun-

denzufriedenheit sicher?

Leistungsfähigkeit Transparente Services zu einem opti-

malen Kosten-/Nutzenverhältnis.

Wie kann die EZV ihre Kosten-Nut-

zen-Relation verbessern und ihre

Ressourcen optimal einsetzen?

Mobilität Mobile Informationsverarbeitung, -

auswertung und -plausibilisierung in

Echtzeit.

Wie kann die Ortsunabhängige Infor-

mationsbewirtschaftung sichergestellt

werden?

Informationssicherheit Rollenbasierte Authentifizierung und

sichere Verwaltung von sensitiven

Daten.

Wie kann der Missbrauch von Infor-

mationen durch illegitime Ressour-

cennutzung verhindert werden?

Tabelle 14: Geschäftsprinzipien unterteilt in Kerngeschäft und Erfüllungsgrad

Die zugeteilten Geschäftseigenschaften beschreiben, wie die angestrebten SOLL-Eigenschaften den



54/107

Prinzipien folgen.

Abbildung 21: Geschäftsfunktionsmatrix

Eine Gegenüberstellung der einzelnen Prinzipien zeigt ihre Wirkung zu einander. In nachfolgender Abbil-

dung ist ersichtlich welche Prinzipien im Konflikt stehen, bei welchen eine nähere Prüfung nötig ist und

welche sich neutral oder sogar sich gegenständig in ihrer Wirkung verstärken.



55/107

Abbildung 22: Wirkungsmatrix Geschäftsprinzipien

Integration vs. Evolution

Das Prinzip der Integration stellt sicher, dass Anwendungen und Daten zentral und durchgängig verwal-

tet werden können. Bei der Evolution wird versucht, Trends und zukünftige Erweiterungen in der IKT zu

definieren. Stark integrierte Systeme erleichtern die Informationsbewirtschaftung, stellen aber bei Anpas-

sungen und Erweiterungen eine eher grössere Komplexität dar.

IT-for-Business vs. Leistungsfähigkeit

Durch die Aufnahme von Bedürfnissen und Anforderungen von Geschäftstätigkeiten können Anwendun-

gen effizienter und intuitiver gestaltet werden. Die Erhebung und Umsetzung von Anforderungen und Be-

dürfnissen sind aufwendig und können kostenintensiv sein. Die Wirtschaftlichkeit von Änderungen ist im-

mer in Betracht zu ziehen.

Informationssicherheit vs. Leistungsfähigkeit

Die Informationssicherheit in der IKT ist zentral und unumgänglich. Vertrauliche Daten müssen vor unbe-

rechtigtem Zugriff geschützt werden. Nicht alle Informationen benötigen ein grösstmögliches Mass an

Zugriffssicherheit. Es ist wichtig zu definieren, welche Informationen wie gesichert werden sollen um mit

minimalem Aufwand und Kosten ein Maximum an Sicherheit gewährleisten zu können.

Mobilität vs. Informationssicherheit

Eine effiziente und zeitgemässe Arbeitsweise sieht vor, dass Informationen ortsunabhängig bezogen,

erstellt und verarbeitet werden können. Durch einen Informationszugriff ausserhalb eines klar definier-

ten, sicheren Bereiches entsteht in der Regel ein grösserer Sicherheitsbedarf. Eine grössere Zugriffssi-

cherheit geht meist mit aufwendigeren und zeitintensiveren Authentifizierungen einher.



56/107

4.2 Informationssystemarchitektur

Die Informationssystemarchitektur richtet sich an den erarbeiteten Geschäftsprinzipien und Geschäfts-

funktionen aus und hat zum Ziel, die Geschäftsprozesse möglichst effizient zu unterstützen. Zu diesem

Zweck werden die Geschäftsobjekte sowie die Anwendungslandschaft festgelegt.

Für die Definition der Architektur werden übergeordnete IT-Prinzipien für die Bereiche Daten und An-

wendungen definiert. Diese sind mit den allgemeinen Architektur Prinzipien vom BIT und den Weisung

über die Referenzarchitektur für Fachanwendungen im Eidgenössischen Finanzdepartement abgegli-

chen.

Der Katalog der Geschäftsobjekte wurde auf der Basis des Entwurfs aus der IST-Architektur GAR-EZV

[GAR-ISTARCH] in breit abgestützten Workshops weiterentwickelt, sodass nun ein umfassender Ge-

schäftsobjektkatalog mit unternehmensweiter Gültigkeit vorliegt.

Basierend auf den erhobenen Geschäftsfunktionen (vgl. Kapitel 4.1.4) werden IT-Funktionen10 abgelei-

tet. Dabei konnten die fachlichen und technischen IS-Services aus dem Projekt Redesign Fracht wie

auch die System Use Cases aus VSP weitestgehend übernommen werden. Die identifizierten IT-Funkti-

onen sind fachlicher wie auch technischer Natur. Ihre Ausgestaltung soll grundsätzlich das Prinzip der

Wiederverwendbarkeit unterstützen damit sie bei Bedarf von mehreren Anwendungen genutzt werden

können.

Die erhobenen IT-Funktionen werden in der Folge nach fachlichen und technischen Kriterien gebündelt.

Auf dieser Basis lassen sich die erforderlichen funktionalen Anwendungen herleiten. Zur Übersicht wer-

den die Anwendungen auf ein logisches Modell gelegt. Damit ist eine wichtige Grundlage für kontrollier-

tes Architekturmanagement gelegt.

Als Nebenprodukte der Arbeiten entstand eine umfassende Liste der erforderlichen IT-Funktionen, inkl.

grober Beschreibung und einem Verweis zu Redesign Fracht oder VSP wenn relevant. Ebenfalls liegt

eine erste Übersicht der IT-Funktionen pro Anwendung vor. Mit diesen Resultaten ist ein guter Grund-

stein für ein kontrolliertes Architekturmanagement gelegt.

4.2.1 IT-Prinzipien

Die nachfolgenden Prinzipien basieren auf den Geschäftstreibern von GAR-EZV und den allgemeinen

Architektur-Prinzipien vom BIT. Sie sind ebenfalls abgestimmt mit den übergreifenden Prinzipien der Re-

ferenz Architektur EFD11. Die Prinzipien sind auf den Ebenen Daten, Anwendung und Technologie (vgl.

Kapitel 4.2.1.1) erfasst.

4.2.1.1 Struktur der IT-Prinzipien

Ein Prinzip wird durch die folgenden Angaben gemäss TOGAF beschrieben.

Der Name (name) beschreibt den Inhalt und die Essenz des Prinzips. Der Name ist verständlich und

10 Die IT-Funktionen sind den IS-Services aus Redesign Fracht bzw. den System Use Cases aus VSP gleichzusetzen 11 Die „Weisung über die Referenzarchitektur für Fachanwendungen im Eidgenössischen Finanzdepartement“ ist zur Zeit in Ver-

nehmlassung



57/107

muss leicht zu merken sein. Spezifische Plattformen- oder Technologiebezeichnungen sollten nicht er-

wähnt werden. Unklare Begriffe, die verschiedentlich interpretiert werden könnten, sind zu vermeiden.

Die Aussage (statement) beschreibt die fundamentale Regel klar und unmissverständlich.

Die Begründung (rationale) hebt den Nutzen für das Geschäft, der durch die Beachtung des Prinzips

gewonnen wird, hervor. Ähnlichkeiten zwischen den Geschäfts-Prinzipien und den technisch orientierten

Prinzipien sollten aufgezeigt werden. Die Abhängigkeit zwischen den verschiedenen Prinzipien und de-

ren Hierarchie untereinander sollten beschrieben werden, um eine Entscheidung zu erleichtern.

Die Auswirkung (implications) auf das Geschäft, die Kosten, die benötigten Ressourcen und die auszu-

führenden Aktivitäten werden klar und eindeutig aufgezeigt.

4.2.1.2 Datenprinzipien

Prinzip D1 Gemeinsame Nutzung der Daten

Aussage Gemeinsame Nutzung von zentral abgelegten Daten durch die entsprechenden Zugriffe ermöglichen

Begründung

Reduktion von Datenredundanzen und damit Erhöhung der unternehmensweiten Datenkonsistenz

Vorbedingung um Open Government Data effizient umsetzen zu können

Kostengünstigere Datenhaltung aufgrund von weniger Redundanzen

Erhöhung der Auswertungsqualität durch widerspruchsfreie Datenbestände

Auswirkung

Definition von standardisierten Datenmodellen (z.B. Geschäftsobjektmodell), Datenbeschreibungen

und Metadaten ist Voraussetzung für eine gemeinsame Nutzung

Daten aus Altsystemen müssen ggfls. migriert oder in ein angepasstes Modell überführt werden, da-

mit diese gemeinsam genutzt werden können

Tabelle 15: Prinzip D1 – Gemeinsame Nutzung der Daten

Prinzip D2 Einheitliche Modelle

Aussage Datenobjekte und Datenmodelle werden unternehmensweit einheitlich und widerspruchsfrei definiert.

Begründung

Voraussetzung für eine gemeinsame Datennutzung für Open Government Data Ansätze

Vereinfachung des Datenaustausches zwischen Anwendung wie auch mit anderen Organisationen

Datenauswertungen und Analysen sind einfacher und die Resultate konsistent

Auswirkung

Jedes Geschäftsdatenobjekt wird einer Person (business owner) aus dem jeweiligen Fachbereich

zugewiesen. Änderungen am Objekt oder am Modell müssen von diesen verantwortet werden.

Unternehmensweit einheitliche Definition von Begrifflichkeiten und Führen eines Glossars

Tabelle 16: Prinzip D2 – Einheitliche Modelle



58/107

Prinzip D3 Datensicherheit

Aussage Die Daten müssen bezüglich Verfügbarkeit, Vertraulichkeit, Integrität und Nachvollziehbarkeit gemäss

den Vorgaben des Datenherrn geschützt werden.

Begründung

Weisungen des ISB über die Informatiksicherheit in der Bundesverwaltung (WIsB)

Bundesgesetzt über den Datenschutz (DSG, VDSG)

Informationsschutzverordnung (ISchV)

Auswirkung Die gemeinsame Nutzung der Daten bedingt besondere Vorkehrung zum Datenschutz

Die Daten müssen alle so geschützt werden wie es das Datum mit dem höchsten Schutzbedarf un-ter ihnen vorgibt (Maximumprinzip).

Tabelle 17: Prinzip D3 – Datensicherheit

4.2.1.3 Anwendungsprinzipien

Prinzip A1 Fokussierung

Aussage Anwendungen werden auf dedizierte Geschäftsfunktionen sowie fachlich, funktionale Bereiche fokus-

siert.

Begründung

Eine Fokussierung der Anwendungen auf Ihre Geschäftsfunktionen führt zur Reduktion von funktio-

nalen Redundanzen in der Anwendungslandschaft der EZV.

Die funktionale Fokussierung auf einen Anwendungsbereich erhöht deren Austauschbarkeit und

Wiederverwendbarkeit

Die funktionale Fokussierung einer Anwendung führt zur Verringerung der Komplexität innerhalb der

Anwendung

Auswirkung

Eine Architektur Governance muss etabliert und mit den erforderlichen Kompetenzen ausgestattet

sein

Neue oder erweiterte Fachanforderungen müssen durch die Architektur Governance geprüft und

konsequent den entsprechenden Fachanwendungen zugewiesen werden.

Funktionen werden in einer Anwendungslandschaft „zentral“ angeboten, dadurch erhöht sich das

Integrationsbedürfnis zwischen den einzelnen Anwendungen. (z.B. Kundendaten werden aus-

schliesslich in der Kundenverwaltung gehalten. Das bedeutet, dass die anderen Fachanwendungen

diese Daten von dort beziehen müssen Integration / Schnittstelle)

„zentral“ zur Verfügung gestellte Funktionen müssen den Verfügbarkeitsanforderungen der kritischs-

ten Anwendung genügen

Tabelle 18: Prinzip A1 – Fokussierung



59/107

Prinzip A2 Modularität

Aussage Anwendungen und Anwendungsbausteine sollen konsequent modular und entlang definierter Schnitt-

stellen aufgebaut werden

Begründung

Funktionale Änderungen (Projekte/statische Sicht) oder Ausfälle (Laufzeit) haben oft nur einen loka-

len Charakter und sind deshalb einfacher handhabbar.

Wiederverwendbarkeit von Modulen und damit Skaleneffekte in Design, Entwicklung und Betrieb

durch die gemeinsame Nutzung von Komponenten, sowie Kostenreduktion durch die Vermeidung

von redundanten Entwicklungen

Auswirkung

Bereits auf fachlicher Ebene muss das Prinzip der Modularität verankert und entsprechend in Projek-

ten eingebracht werden (nicht nur ein IT-Thema)

Modulare und serviceorientierte Bauweise (SOA) muss bei neuen Diensten und Funktionalität einge-

fordert werden. Dies kann eine leichte Erhöhung der Initialkosten zur Folge haben.

Höchstmögliche Autonomie durch lose Kopplung der Anwendungen und Anwendungsbausteine

muss konsequent eingefordert werden.

Komponenten welche potentiell wiederverwendet werden können, müssen skalierbar konzipiert und

entwickelt werden.

Tabelle 19: Prinzip A2 - Wiederverwendbarkeit durch Modularität

Prinzip A3 Plattformunabhängigkeit

Aussage Anwendungsclients sind plattformunabhängig

Begründung

Sowohl technische als auch fachliche Unabhängigkeit der Clients zu den unterliegenden Anwendun-

gen

Verteilung von Softwareupgrades erfolgt auf Anwendungsebene und nicht auf Client-Ebene

Grösstmögliche Herstellerunabhängigkeit

Auswirkung

Das Design und die Entwicklung von Anwendungen wird so ausgestaltet, dass keine lokalen Installa-

tionen auf den Arbeitsstationen der Benutzer erforderlich sind

Die GUI’s sollen in der Regel Browser basiert sein

Tabelle 20: Prinzip A3 - Plattformunabhängigkeit

Prinzip A4 Unternehmensweite Integrationsplattform

Aussage Für die Integration bestehender und neuer Anwendungen und Services wird eine standardisierte Integ-

rationsschicht eingesetzt. Die angebotenen Services sind in einem zentralen Verzeichnis registriert.

Begründung

Fördert die Wiederverwendbarkeit von Services

Integration von unterschiedlichen Technologien über eine einheitliche Plattform

Reduktion der technischen Beziehungen zwischen den einzelnen Anwendungen

Auswirkung

Ein Enterprise Service Bus muss unternehmensweit eingeführt werden

Wiederverwendbare Services müssen definiert und konsequent umgesetzt werden

Die Services sollen in einem zentralen Serviceinventar verwaltet werden

Tabelle 21: Prinzip A4 - Unternehmensweite Integrationsplattform



60/107

Prinzip A5 Web und Mobile

Aussage Das Design von neuen Anwendungen soll grundsätzlich den Zugang über Internet und die Einbindung

von Mobilgeräten ermöglichen

Begründung

Die Kommunikation mit den Kunden erfolgt vermehrt online und über die unterschiedlichsten Endge-

räte

Steigerung der Effizienz und Effektivität bei ortsunabhängigem Einsatz von EZV Mitarbeitern

Auswirkung

Adaptives Design der Benutzeroberfläche zur Erreichung von Endgeräteunabhängigkeit (responsive

design)

Netzzonenkonzept muss ggfls. angepasst oder erweitert werden.

Die Sicherheitsbestimmungen für den Zugriff über Internet sind vollumfänglich zu erfüllen (z.B. 2-

Faktor-Authentisierung)

Erschwerte Integration zwischen neuen und alten Plattformen aufgrund von Sicherheitsthemen.

(Netzzonenübergänge etc.)

Tabelle 22: Prinzip A1 - Web und Mobile

Es ist essentiell, dass die Prinzipien über das Projekt GAR-EZV hinaus durch ein Architektursteuerungs-

organ bei den Projekten der EZV konsequent eingefordert werden.

4.2.2 Geschäftsobjektkatalog

Ein unternehmensweiter, abschliessender Katalog der Geschäftsobjekte bildet die zwingende Grundlage

für die Erfüllung des Datenprinzips D2 „Einheitliche Modelle“. In mehreren breit abgestützten Workshops

und Review-Zyklen wurde die, während der IST-Architektur GAR-EZV Version 0.9112 [GAR-ISTARCH]

erarbeitete, Geschäftsobjektliste überarbeitet, ergänzt und schliesslich im Rahmen der Studie GAR-EZV

finalisiert. Das Resultat ist der nachfolgende Geschäftsobjektkatalog, welcher eine unternehmensweite

Abdeckung hat.

Geschäftsobjekt Beschreibung

Abgabe

Die Abgabe ist der von einem Kunden geschuldete Betrag aufgrund von Rechtsvorschriften. Der

Abgabenbetrag oder die Abgabenforderung basiert in der Regel auf einer Veranlagungsverfü-

gung.

Abschluss

Stellt ein finanzielles Aggregat der einzufordernden Abgaben und zu leistenden Rückerstattun-

gen dar, die innerhalb eines Zeitraums (z.B. Tag, Monat) auszuführen sind. Kann Einzelpositio-

nen und/oder Saldo ausweisen.

Anfrage

Anfragen von unterschiedlichen Kunden und Partnern welche von der EZV beantwortet werden.

So werden Anfragen zu Zollformalitäten, politische Anfragen und Vorstösse, Ursprung, Tarif,

usw. behandelt.

Anmeldung

Die Anmeldung ist das Bekunden des Kunden, die Ware, Warenbewegung oder Leistung der

Behörde zu melden und damit in ein Zoll-, Steuer-, Rückerstattungs- oder Abgabenverfahren zu

überführen.

Beispiele: Deklaration [km] LSVA, baugewerbliche Leistung MWST, etc.

12 Die Version 0.91 wurde am 1. PAS diskutiert. In der Version 1.0 der IST-Architektur GAR-EZV wurde ebenfalls der finalisierte

Geschäftsobjektkatalog integriert, dies zu Gunsten einer konsequenten Durchgängigkeit und zur Vorbeugung von Missver-ständnissen

http://de.wikipedia.org/wiki/Rechtsvorschrift



61/107


Auswertung

Die Auswertung ist die Aggregation von Daten nach bestimmten Kriterien basierend auf Daten-

analysen und stellt eine globale, homogene Sicht auf heterogene Daten aus unterschiedlichen

Quellen sicher.

Beispiele: Statistiken, Risikoanalyse, Lage, etc.

Beförderungsmittel

Beförderungsmittel mit dem Ware transportiert oder eine abgabenpflichtige Leistung wie Ver-

kehrsabgaben erbracht wird.

Beispiele: Fahrzeug, Flugzeug, Schiff, Rohrleitung, etc.

Befund

Dokumentiertes Ergebnis einer Kontrolle. Dies kann Aufschluss über allfällige Sanktionen ge-

ben.

Beispiele: Warenbeschau, Personenkontrolle

Behörde Staatliche Einrichtung, die für die Erfüllung gesetzlich vorgeschriebener Aufgaben der Verwal-

tung des jeweiligen Staates zuständig ist.

Benutzer Interner oder externer Benutzer einer Fachanwendung der EZV.

Beschwerde Beschwerde eines Kunden bspw. gegen eine Verfügung oder bezüglich Verhaltensweise.

Dies beinhaltet ebenfalls formelle Einsprachen zur Anfechtung einer Verfügung.

Bewilligung

Positiver Bescheid der Verwaltung zur Ausübung von bestimmten, genau umschriebenen Tätig-

keiten. In der Regel unter Auflage von Pflichten.

Beispiel: Kontingente, Einreisvoraussetzung wie Visa, etc.

Dienststelle Amtliche Einrichtung der EZV an der Grenze, im Inland oder im Ausland.

Dokument

Ein amtliches (z.B. Urkunde, Ausweisdokument, Verantwortlichkeitsmarke, Prüfzertifikat etc.) o-

der nicht amtliches Schriftstück auf Papier oder eine in Dateiform angelegte oder durch Digitali-

sierung überführte Text- oder Bildinformation.

Beispiele amtliches Dokument: Urkunde, Ausweisdokument, Verantwortlichkeitsmarke, Prüfzer-

tifikat, etc.

Beispiele nicht amtliches Dokument: Word, Excel, txt, pdf, digitales Foto, etc.

Gebühr Ein gesetzlich geregeltes Entgelt (z.B. Gebührenverordnung), welches für verschiedene behörd-

liche Tätigkeiten und Dienstleistungen erhoben wird.

Geografische Lage Die geografische Lage definiert den Standort in relevanten Geschäftsvorfällen (z.B. Befund oder

Feststellung)

Geschäftsvorfall Geschäftsrelevantes Ereignis oder Transaktion innerhalb des Unternehmens (EZV). Ein Ge-

schäftsvorfall wird mit einer eindeutigen Identifikation festgehalten und historisiert.

Konto Konto eines Kunden über das Abgaben bezahlt sowie Rückerstattungen vorgenommen und Si-cherheiten geleistet werden können.

Kunde

Natürliche oder juristische Person, die gegenüber der EZV Pflichten, Rechte oder andere Kun-

denbedürfnisse hat. Als gleichwertiges Synonym für Kunde gelten auch die Begriffe Zollbeteilig-

ter, Abgabepflichtiger und Rückerstattungsberechtigter.

Beispiel Pflichten: zuführungspflichtig, anmeldepflichtig, abgabenpflichtig, steuerpflichtig, aus-

weispflichtig, dokumentenpflichtig

Beispiel Rechte: steuerbegünstigungsberechtigt, rückerstattungsberechtigt, eintragungsberech-

tigt

Lager

Von der Zollverwaltung zugelassener und unter Zollüberwachung stehender Ort im Zollgebiet,

an dem Waren unter den von der Zollverwaltung festgelegten Voraussetzungen gelagert werden

dürfen.

Beispiele: Offenes Zollager (OZL), Lager für Massengüter, Zollfreilager, Zugelassenes Lager

(Mineralölsteuer), Zugelassenen Steuerlager (Tabaksteuer), etc.



62/107


Massnahme Von der EZV verhängte Massnahmen im Zusammenhang mit Wiederhandlungen zu rechtlichen Bedingungen. (z.B. Anzeige, Busse, Kaution, administrativ Massnahme, Strafe)

Meldung Nachricht behördenintern oder zwischen Kunden und Behörden (auch EZV-intern).

Rechnung Eine schriftliche/elektronische Aufforderung zur Zahlung eines Geldbetrages

Produkt

Das Objekt Produkt steht für ein Produkt, eine Ware oder eine Leistung, welche für einen abga-

ben- oder steuerauslösenden Sachverhalt steht.

Beispiele: lösemittelhaltige Anstrichfarbe, Kleidung aus Baumwolle, Spirituose,

Benzin, Abgabenkategorie (LSVA),etc.

Sachanlage Eine bei der EZV gemeldete technische Anlage oder Maschine(z.B. Pistenfahrzeug), für deren Betrieb ein Produkt (z.B. Diesel) verwendet wird, für welches Steuern erhoben und/oder zurück-erstattet werden

Sachmittel Erforderlich Mittel und Materialien zur optimalen Unterstützung bei der Erfüllung der EZV Aufga-

ben.

Beispiele: Ausrüstung, Infrastruktur, Techn. Hilfsmittel

Sicherheiten

Vom Kunden hinterlegte Sicherheiten zur Absicherung des Kreditrisikos. Die Sicherheiten kön-

nen durch den Gegenwert von Geld, Sachwerten oder durch die Bonität von anderen Unterneh-

men oder Personen gewährleistet werden.

Verfahrensdossier Umfasst sämtliche Daten und Dokumente im Zusammenhang eines Verfahrens. Darunter fallen auch Strafuntersuchungen in denen gegebenenfalls eine Massnahme vollzogen wird.

Verfügung

Anordnung der EZV im Zusammenhang mit einem Abgaben-, Zoll- und/oder Strafverfahren, mit der im Einzelfall ein Rechtsverhältnis in einseitiger und verbindlicher Weise und gestützt auf öf-fentliches Recht geregelt wird.

Beispiele: Abgaben, Sicherheiten, Rückerstattungen, Entlastungen, etc.

Zahlung Zahlung eines Kunden an die EZV oder Aus- bzw. Rückzahlung durch die EZV an den Kunden.

Tabelle 23: Geschäftsobjekte

Als weiterer Schritt nach dem Projekt GAR-EZV empfiehlt es sich die Geschäftsobjekte in Bezug zuei-

nander zu stellen und als ein unternehmensweit gültiges Geschäftsobjektmodell zu publizieren. Sämtli-

che Veränderungen oder Ergänzungen im Bereich der Daten sollen in der Folge über dieses Modell ge-

steuert und eingeordnet werden. Zu diesem Zweck muss die Datenverantwortung zwingend geregelt

und etabliert sein.



63/107

4.2.3 IT-Funktionen

4.2.3.1 Einführung

Eine IT-Funktion13 stellt eine eindeutig identifizierbare Aufgabe innerhalb einer Fachanwendung dar. Die

inhaltliche Ausprägung kann dabei fachlich oder technisch orientiert sein. Grundsätzlich sind IT-Funktio-

nen zudem wiederverwendbar, d.h. eine Funktion kann in mehreren Fachanwendungen zum Einsatz

kommen. Eine typisch fachlich geprägte IT-Funktion ist z.B. Selektion ausführen. Die fachliche Logik

wird in einem Software-Modul abgebildet und es ist durchaus denkbar, dass im Bereich Warenverkehr

Grenze und Abgaben für bestimmte Tätigkeiten die identischen Selektionsregeln angewendet werden

können (Wiederverwendbarkeit). Als typisch technische IT-Funktion kann Daten ver-/entschlüsseln auf-

geführt werden. Bei diesem Vorgang ist die fachliche Bedeutung der betroffenen Daten irrelevant. Tech-

nische IT-Funktionen sollen grundsätzlich nach dem Prinzip der Wiederverwendbarkeit konzipiert und

erstellt werden.

Aus funktionaler Sicht sind IT-Funktionen die kleinstmöglichen Bestandteile mit definiertem Input, Ver-

halten und Output. Das Zusammenspiel einer Anzahl IT-Funktionen ergibt die Abbildung eines informati-

sierten Geschäftsprozesses, wobei die Ablauflogik typischerweise von einer Prozesssteuerung wahrge-

nommen wird.

4.2.3.2 Liste der IT-Funktionen

Die in der EZV benötigten IT-Funktionen werden einerseits aufgrund der in GAR-EZV ermittelten Ge-

schäftsfunktionen (siehe 4.1.4) abgeleitet. Andererseits wurden auch die Arbeitsergebnisse aus den Pro-

jekten Redesign Fracht (IS-Services) und VSP (System Use Cases) beigezogen. Die funktionalen Er-

kenntnisse aus den beiden Projekten konnten nahezu vollständig übernommen und somit bestätigt wer-

den. Daraus resultiert ein, nach heutigen Gesichtspunkten, unternehmensweit umfassender Katalog von

rund 140 IT-Funktionen.

Eine Vielzahl der IT-Funktionen wird in der Folge in mehreren Anwendungen wiederverwendet, deshalb

ist eine Zuweisung auf die Geschäftsfelder an dieser Stelle nicht sinnvoll.

Die nachfolgende Tabelle enthält alle identifizierten IT-Funktionen. Im Anhang, Kapitel 7.6 werden die

einzelnen IT-Funktionen kurz beschrieben und sind gekennzeichnet, ob sie auch in Redesign Fracht o-

der VSP beschrieben wurden. Ist dies der Fall, kann in den entsprechenden Dokumentationen jeweils

eine detailliertere Beschreibung gefunden werden.

13 IT-Funktionen haben die gleiche Bedeutung wie die IS-Services in Redesign Fracht



64/107

IT-Funktionen

Abgaben / Rückerstattungen / Gebühren / Entlastungen festsetzen

Abgaben erheben

Administrativmassnahmen behandeln

Amts- und Rechtshilfe behandeln

Analysen und Recherchen bei Vorermittlungen

Anbindung an Dokumentenverwaltung

Anbindung an Elektronische Aktenführung

Anbindung an Fahndungssysteme

Anbindung an Personenidentifikationssystem

Aufzeichnung der Informationsflüsse (Kunde, Ge-schäftsfall, Ereignis)

Ausbildungszertifikate und Schulungskonzepte verwalten

B2B Filetransfer

Bargeldhinterlagen verwalten

Beanstandungen melden und verwalten

Benutzer registrieren und verwalten (Registrierung)

Beschlagnahmte Ware verwalten

Beschwerden behandeln

Bewilligung erteilen und verwalten

Bewilligung prüfen und abschreiben

Büroanwendungen

Complex Event Processing (CEP)

Customer Self Services

Daten 2-stufig übermitteln

Daten abonnieren

Daten austauschen

Daten für Auswertungen integrieren

Daten mit Sicherheitsorganen austauschen

Daten transformieren und routen

Daten transportieren

Daten ver-/entschlüsseln

Datenauswertungen erstellen

Datenintegrität schützen

Datenspeicher bereitstellen

Datenspeicher verwalten

Datenverkehr überwachen

Datenverwaltung und Aufbereitung für Webseiten

Debitorenbuchhaltung führen

Dokumente aufbereiten

Dokumente digitalisieren

Dokumente verwalten

Echtzeit Informationsverfügbarkeit

Edelmetallware Bewilligungen und Verantwortlichkeitsmarken verwalten

Edelmetallwarenanalyse steuern und ausführen

Edelmetallwarenpunzierung steuern und ausführen

Ein- und Auszahlung

Einsatz Rapportierung

Einsatzmittel, Einsatzereignisse und Einsätze verwalten

Einsatzplanung für Personal und Material

Elektronisch erfassen (WebGUI)

Elektronische Aktenführung

Elektronische Datenlagerung

Endgeräte unabhängige Oberflächen (Responsive Web Design)

Informations-Crawler (Erntemaschine)

Issue Tracking / Trouble Ticketing

Journal führen

Journaldaten automatisch übernehmen

Kalkulation in Abhängigkeit von verschiedenen Parametern

Kassenabschluss und Ablieferung

Kassenzahlung leisten

Kommunikation mit Armee und Polizei (ad hoc)

Kommunikationskanäle bereitstellen (ad hoc)

Kontingente erteilen und entziehen

Kontingente prüfen und abschreiben

Kontrollbefund dokumentieren

Kontrolle von Reisedokumenten

Kreditorenbuchhaltung führen

Kunden bewerten

Kunden verwalten

Labor Notebooks führen

Mahnwesen für Kreditoren und Debitoren

Materialanalyse durchführen

Materielle Kontrolle durchführen

Materielle Kontrolle planen und vorbereiten

Meldung / Formular verarbeiten

Mobile Biometrie-Datenerfassung

Mobiler Zugriff auf Applikationen

Niedrige Bandbreite unterstützen

Nutzer authentisieren und autorisieren

Offene Forderungen einziehen (Inkasso)

Offline-Web-Technologie

Online Zahlung leisten

Open Data Services

Ortung

Partner Access Policy Enforcement

Pendenzen-/Statusliste führen

Plausibilisierung durchführen

Portal-Integration und -Lenkung

Präsentation der Daten

Prozessablauf steuern

Realtime analytics

Referenzdaten bereitstellen

Referenzdaten beziehen und interpretieren

Referenzdaten verwalten

Risikoanalyse und Reporting

Rollen- und Berechtigungskonzept

Rückerstattungen gutschreiben

Sachanlagen verwalten (führen und bewirtschaften)

Selektion ausführen

Selektionsregeln definieren

Sicherheiten verwalten

Social Collaboration

Stationäre Biometriedatenerfassung

Strafverfahren behandeln

Suchanfrage verarbeiten

Technische ID's verwalten

Temporale Datenhaltung (Historisierung)

Transportmittel verwalten

Veranlagungsverfügung ausstellen



65/107

IT-Funktionen

Entlastungen auf Abgaben leisten

Ereignis verwalten

Fahndung oder Überwachung initiieren

Fakturierung inkl. Versand

File Sharing

Fliegende Einsatzsysteme, Drohnen

Formelle Bearbeitung

Frist berechnen

Fristeinhaltung überprüfen

Fristen definieren

Geo-Informationsaufbereitung

Geschäftsfall verwalten

Geschäftsregeln verwalten und applizieren

Hauptbuch führen

Hochsensible Daten verwalten

IKS Prüfung Freigabe

Information abfragen (Kunde, Geschäftsfall, Ereignis)

Information übermitteln (Kunde, Geschäftsfall, Ereignis)

Veranlagungsverfügung eröffnen

Vergleich von unabhängigen Prozessen

Vernetzte on-demand Informationsabfrage

Verwendungsverpflichtung erteilen und verwalten

Verwendungsverpflichtung prüfen

Verzeichnisdienst (Identity Store)

Vorhandene Daten übernehmen

Warenbuch führen (Kunde, Produkt, Standort)

Warenfluss verwalten

Warenvergleich durchführen

Wissensmanagement

Zellüberwachung

Zentralen Zugriff bereitstellen

Zertifikat prüfen

Zertifikate verwalten

Zoll-Pad

Zollregister (Verzeichnisse) publizieren

Zollregister (Verzeichnisse) Suchfunktion

Tabelle 24: Liste der IT-Funktionen

4.2.4 Anwendungen

4.2.4.1 Herleitung

In diesem Kapitel werden die Anwendungen der SOLL-Architektur aufgrund der identifizierten Ge-

schäfts- und IT-Funktionen hergeleitet und beschrieben. Die Betrachtung erfolgt dabei auf logischer

Ebene um eine geeignete funktionale Struktur der Anwendungslandschaft zu definieren. Die resultie-

rende Struktur stellt die unternehmensweite SOLL-Architektur der EZV dar.

Zur Herleitung der Anwendungen werden die im vorhergehenden Kapitel identifizierten IT-Funktionen

nach den folgenden Kriterien zusammengefasst.

Fachliche Homogenität der Funktionen

Technologische Homogenität

Modularität und Wiederverwendung (z.B. Finanzsystem)

Verwendung von Standards (z.B. Dokumenten Management System)

Hoher Interaktionsgrad entlang eines operativen Geschäftsprozesses

Minimierung der Schnittstellen zwischen Anwendung innerhalb eines Geschäftsprozesses

Der Bündelung von IT-Funktionen zu Applikationen sind gemäss Fokussierungs-Prinzip jedoch klare

Grenzen zu setzen. Diese ergeben sich aus dem unterschiedlichen Nutzungskontext der IT-Funktionen,

welche differierende Anforderungen an eine Anwendung z.B. hinsichtlich Verfügbarkeit oder

Performance zur Folge haben können.

Für die effektive Umsetzung der identifizierten Anwendungen wird es in der Regel eine Vielzahl an

Lösungsmöglichkeiten geben. Die erforderlichen Designentscheidungen (make or buy, Technologie etc.)

müssen im Rahmen der individuellen Projekte gefällt werden.



66/107

4.2.4.2 Anwendungslandschaft

Die Fachanwendungen sowie die Komponenten der Zugangskanäle, Integration, IT-Sicherheit und Ba-

sisdienste sind unter Kapitel 4.1.4.1.2 aufgeführtem Funktionsmodell dargestellt. Mit dieser rein funktio-

nalen Kategorisierung ist eine gute Grundlage für das Architekturmanagement geschaffen, welche voll-

umfänglich unabhängig von Organisationsstrukturen ist.

Die funktionale Zuordnung der Anwendungen wiederspiegelt die Prinzipen der Fokussierung und

Modularität. Im Zentrum stehen die Fachanwendungen, welche entweder fachliche Funktionen pro

Geschäftsfeld abdecken oder aber Querschnittsaufgaben wahrnehmen. Da die Anwendungen auf diese

Aufgaben fokussiert werden, können sie dem entsprechenden Geschäftsfeld oder einem

Funktionsbereich der allgemeinen fachlichen Dienstleistungen zugeordnet werden.

Über die Integration und Prozesssteuerung werden die Fachanwendungen geschäftsfeldübergreifend

miteinander verbunden. Des Weiteren werden die Funktionen und Komponenten des zentralen Zugangs

von den Fachanwendungen entkoppelt und somit das Prinzip der Plattformunabhängigkeit unterstützt.

Über die B2B-Komponente wird die Maschine-zu-Maschine Kommunikation mit Kunden und Partner-

behörden kanalisiert und von den Fachanwendungen entkoppelt.

Die optionale Workflow Komponente dient dazu übergreifende Geschäftsprozesse zu steuern. Zum

heutigen Zeitpunkt liegen allerdings keine konkrete Anfroderungen vor, die einen Einsatz rechtfertigen

würden. Aus diesem Grund ist die Workflow Komponente in der nachfolgenden Abbildung nur

angedeutet (schraffiert).

Abbildung 23: Anwendungslandschaft



67/107

Der zentrale Zugang ermöglicht sowohl für Kunden, Partnerbehörden wie auch für die internen Benutzer

rollenbasierte Zugriffe auf die erforderlichen Funktionen und Daten. Mit dem Portal wird die Möglichkeit

eines Single-Sign-On und Single Window geschaffen, sprich, man kann mit einem Login auf alle

zugewiesenen Anwendungen, Funktionen und Daten zugreifen. Durch die konsequente Ausrichtung auf

browserbasierte Benutzeroberflächen sowie die Unterstützung von mobilen Endgeräten wird ortsunab-

hängiges Arbeiten und die Bereitsstellung von Funktionen zur Kundenselbstdeklaration über Internet

ermöglicht.

Komplettiert wird der zentrale Zugang mit der Informationsaufbereitung für Webseiten und der

Handhabung von papierbasierter Kommunikation mittels Druckstrassen und Scanning.

Der Bereich der IT-Sicherheit deckt die erhöhten Anforderungen durch die Zugriffe über das Internet ab.

Dazu gehört insbesondere die konsequente Anwendung von Identity & Access Management (IAM), eine

zentrale Benutzer- und Rollenverwaltung, die Verwaltung und Vergabe von elektronischen Schlüsseln

und Signaturen. Durch den vermehrten Einsatz von mobilen Endgeräten wird die Verwaltung dieser

unter sicherheitsrelevanten Aspekten durch ein Mobile Device Management erforderlich. Weitere Details

zu den Sicherheitsanfoderungen sind dem Anhang Kapitel 4.2.5 zu entnehmen.

Die Basisdienste decken die Themen der IT-Grundinfrastruktur ab. Im Bereich der Büroautomation oder

generell der Softwareverteilung sollten im Rahmen von zollspezifischer Software die einzelnen Produkte

der Schalen 1-3 punktuell diskutiert und allenfalls in spezifische Verteilungspakete aufgenommen

werden.

Im Bereich der Infrastruktur basiert die EZV grundsätzlich auf VDI. Dies ist aufgrund der über 300

Standorte allein aus Support Gründen nachvollziehbar. Andereseits stellt die VDI oft ein Hindernis bei

der Einführung neuer Dienste wie bspw. UCC dar. Dieser Themenkreis wird zurzeit von einem

dedizierten Team ausserhalb der GAR-EZV Studie analysiert. Resultate und mögliche Massnahmen

sollen planmässig per Ende Q3/15 und damit zeitgleich mit dem Abschluss der GAR-EZV Studie

vorliegen.

Ähnlich verhält es sich bei den Netzwerkdiensten. Im Bereich der Netzzonen wird zurzeit eine neue

Struktur diskutiert. Wenn diese umgesetzt ist, wird der Zugriff aus dem Internet einfacher handhabbar

sein als heute. Die Situation wird sinnvollerweise erst zum Zeitpunkt von konkreten

Umsetzungsprojekten analysiert um entsprechende Design-Entscheide zu fällen.

Ein weiteres wichtiges Netz für die EZV ist das Funktnetz Polycom. Dieses wird mit dem VBS

gemeinsam genutzt und bleibt bis auf Weiteres gesetzt und hat somit auf GAR-EZV keinen direkten

Einfluss.

Im Rahmen der GAR-EZV Studie werden die Basisdienste nicht weiter detailliert.

Die Bereiche Führung & Unterstützung, nationale / internationale Partner wie innere Sicherheit sind nicht

im Fokus von GAR-EZV. Als einzige Ausnahme aus diesen Bereichen ist eine Anwendung Entreprise

Architecture Management aufgeführt. Dies weil zur effizienten und kontrollierten Weiterführung und

Pflege der unternehmensweiten Architektur eine Modellierungssoftware und ein dazugehöriges Inventar

unabdingbar sind.

Die vorliegende funktionale Architektur ist an den ursprünglich definierten Geschäftsprinzipien (4.1.3.3)

ausgerichtet. Die Komponenten und Massnahmen der SOLL-Architektur sind nachfolgend pro



68/107

Geschäftsprinzip beschrieben.

Geschäftsprinzip Geschäftsnutzen der Architektur

Integration Mit der Einführung eines unternehmensweiten Geschäftsdatenmodells wird die Grundlage

für harmonisierte Datenmodelle geschaffen. Dies wird es ermöglichen, Muster zu erkennen

oder übergreifende Auswertungen durchzuführen.

Die Anwendungen sind fokussiert auf Ihre Funktionen und Daten und kommunizieren über

eine unternehmensweite Integrationsplattform miteinander. Das bedeutet, dass die Redun-

danzen sowohl bei den Funktionen als auch bei den Daten auf ein Minimum reduziert wer-

den können. Des Weiteren wird mit der Integrationsplattform die Möglichkeit der Wiederver-

wendbarkeit von Funktionen und Integrationsmustern geschaffen.

Kooperation Im Bereich der internen Kooperation erhöht die Konsolidierung von Anwendungen und die

konsequente gemeinsam Nutzung von Daten oder Datenübernahmen für eine verbesserte

Kooperation.

Mit den Kunden und externen Partnern wird durch die Einführung und konsequente Nut-

zung der B2B-Komponente die Möglichkeit geschaffen Daten über standardisierte Dienste

und Schnittstellen auszutauschen. Dabei werden die internen und externen Strukturen ent-

koppelt. Dies erhöht die Änderungsflexibilität und führt schlussendlich zu den gewünschten

Effektivitäts- und Effizienzgewinnen.

Als Option unterstützt die Architektur auch die Grundsätze von Open Government Data und

hilft damit Schranken zur Öffentlichkeit abzubauen.

Evolution Durch eine konsequente Umsetzung von Fokussierung und Modularisierung sowie Tren-

nung von Daten, Geschäftslogik und Präsentation (Benutzerschnittstelle) wird die Ände-

rungsflexibilität erhöht. Durch eine möglichst hohe Plattformunabhängigkeit wird zudem

eine Entkopplung des fachlichen vom technischen Lebenszyklus erreicht.

Die modulare Bauweise sowie die Integrationsplattform bieten die Möglichkeit auf Trends zu

reagieren und bspw. neuartige Technologien in die bestehende Landschaft einzubinden.

IT-for-Business Die Einführung eines Portals (single window), die Unterstützung von single-sign-on sowie

die konsequente Ausrichtung der Benutzerschnittstelle auf Webtechnologien welche auch

über mobile Endgeräte genutzt werden kann, wird die User Akzeptanz nachhaltig verbes-

sern.

Der Einsatz von Prozess-Steuerungskomponenten und allenfalls eines übergreifenden

Workflows bietet die Möglichkeit Geschäftsprozesse nach wirtschaftlichen Grundsätzen zu

automatisieren. Die Effizienz von Prozessen muss über ein geeignetes Prozessengineering

erfolgen, die IT-Lösung wird hier keinen nachhaltigen Einfluss nehmen können.

Zweckmässigkeit Die funktionale Fokussierung der Anwendung ist ein wichtiger Bestandteil um die IT zweck-

mässig auszurichten. Durch den Einsatz von einheitlichen Eingabemasken und möglichst

homogenen Daten sowie die Verfügbarkeit von ausgewählten Funktionen über mobile Cli-

ents wird dem Mitarbeiter die Möglichkeit geboten Daten ortsunabhängig zu validieren oder

zu erfassen.

Leistungsfähigkeit Die Konsolidierung der IT-Landschaft (Reduktion der Anzahl Fachanwendungen um 50%)

sowie die funktionale Fokussierung vermindern die Komplexität der Gesamtlandschaft und

ermöglichen einen fokussierten Einsatz der finanziellen und personellen Ressourcen. Über



69/107

Geschäftsprinzip Geschäftsnutzen der Architektur

die Elimination von Datenredundanzen sowie die Homogenisierung der Daten wird die Da-

tenqualität erhöht was die Leistungsfähigkeit nachhaltig steigert.

Mobilität Die konsequente Ausrichtung der Benutzerschnittstellen auf Webtechnologien und mobile

Unterstützung ermöglicht den ortsunabhängigen Einsatz von Mitarbeitern. Die Verfügbarkeit

von relevanten Daten (z.B. Personenkontrolle) und die Möglichkeit Daten direkt zu erfassen

(z.B. Ereignisrapport) erleichtert u.a. die Einsatzplanung und Einsatzleitung. Des Weiteren

werden ineffiziente Arbeitsabläufe (z.B. doppelte Erfassung von Daten) eliminiert.

Informations-

sicherheit

Die IT-Sicherheit wird auf die Schutzbedürfnisse der Daten ausgerichtet werden. Durch die

Möglichkeit von Zugängen über Internet und die erhöhte Integration zu Kunden und Part-

nern werden die IT-Sicherheitsmassnahmen entsprechend ausgelegt. (IAM, PKI)

Tabelle 25: Bezug Architektur zu Businessprinzipien

4.2.4.3 Liste der Anwendungen

Die nachfolgende Tabelle gibt einen ersten Überblick der identifizierten, notwendigen Anwendungen der

Zukunft inkl. einer Kurzbeschreibung.

Anwendung Kurzbeschreibung

Fachanwendungen „Personenverkehr“

Biometriesystem Anwendung zur Erfassung, Verifizierung und Auswertung von Biometriedaten. Einerseits

können dabei Biometriedaten wie Fingerabdrücke erfasst und an die definierten Auswer-

tungszentren versendet werden. Andererseits kann neben der Erfassung auch die Auswer-

tung von dieser Anwendung übernommen werden (z.B. Gesichtserkennung inkl. Vergleich

mit Angaben im Dokument / Pass).

Fahndungsdaten-

verwaltung

Anwendung zum Verwalten von hochsensiblen Daten, die im Bereich Personenverkehr zum

Suchen und Fahnden verwendet werden.

Ortungssystem Anwendung zur Ortung und Geoinformation. Ortung ist die Positionsbestimmung entfernter

Objekte. Grundlage für eine Ortung ist in der Regel eine vom Beobachter vorgenommene

Distanzmessung mittels Signalen, die vom zu ortenden Objekt an den Sender zurück gelan-

gen. Verwendet werden u.a., Laser, Tonsignale, Radar, GSM. Geoinformationssystem

(GIS) dient der Erfassung, Bearbeitung, Organisation, Analyse und Präsentation räumlicher

Daten.

Reisedokumen-

ten-kontrollsys-

tem

Anwendung im Bereich Personenverkehr zur Kontrolle von Reisedokumenten. Die Anwen-

dung verfügt über eine Anbindung an nationale und internationale polizeiliche Fahndungs-

systeme und ist an die Bedürfnisse von GWK für mobile Einsätze zugeschnitten.

Reiseverkehrs-

überwachung

Anwendung zur Kontrolle vom grenzüberschreitenden Reiseverkehr. Die Anwendung ver-

fügt über eine Anbindung an nationale und internationale polizeiliche Fahndungssysteme,

sowie über die Funktion zur Planung und Erfassung von fliegenden Einsatzsystemen, Defi-

nition und Applikation von Selektionsregeln und ist an die Bedürfnisse von GWK für mobile

Einsätze zugeschnitten.



70/107


Fachanwendungen „Warenverkehr Grenze“

Datenlagerungs-

system

Ein System, welches für die Lagerung der Daten ausserhalb des operativen Systems zu-

ständig ist. Die Datenmenge im operativen System sollte aus Performancegründen so klein

wie möglich, auf ein fachlich und technisch sinnvolles Mass begrenzt werden. Daten auf die

nicht mehr im täglichen Ablauf zugegriffen werden muss, werden im Datenlagerungssystem

langfristig gehalten und sind über geeignete Tools und Zugriffsmechanismen abrufbar.

Warenverkehrs-

system

Fachlicher Anwendungskomplex für den grenzüberschreitenden Warenverkehr, der fol-

gende Komponenten umfasst:

Warenverkehr - beinhaltet die fachliche Funktionalität zur operativen Abwicklung im Be-

reich Warenverkehr.

Plausibilitätskontrolle - Plausibilisierung nach definierten Geschäftsregeln. Neben der

Prüfung auf Vollständigkeit und Schemakonformität von einkommenden Meldungen wer-

den auch die fachlichen Inhalte geprüft.

Complex Event Processing (CEP) - Erkennung, Analyse, Gruppierung und Verarbeitung

voneinander abhängiger Events. Die CEP Funktion umfasst Methoden, Techniken und

Werkzeuge, um Ereignisse kontinuierlich und zeitnah zu verarbeiten und daraus kom-

plexe Ereignissen abzuleiten.

Geschäftsfallverwaltung - Funktionen zur Erfassung, Mutation, Abruf und Bereitstellung

von Geschäftsfall- und Transportmitteldaten, sowie zur Übermittelung von Datenände-

rungen.

Workflow-Management (teilweise) Automatisierung von Geschäftsprozessen auf Basis

einer Spezifikation, für die Ausführung von Arbeitsabläufen.

Business-Rule-Management-System (BRM) - Entwicklung und den Einsatz einer auf Ge-

schäftsregeln basierenden fachlichen Anwendung. Geschäftsregeln werden als Service

bereitgestellt und zur Anwendung aufrufen.

Arbeitsvorrat - Liste von offenen Aufgaben, die zur Bearbeitung nach verschiedenen Kri-

terien zusammengefasst sind. Die Aufgaben werden einer Benutzergruppe oder einem

Benutzer zur Bearbeitung zugewiesen. Der Arbeitsvorrat unterstützt verschiedene Sich-

ten und Filtermöglichkeiten

Fachanwendungen „Abgaben“

Datenlagerungs-

system

Ein System, welches für die Lagerung der Daten ausserhalb des operativen Systems zu-

ständig ist. Die Datenmenge im operativen System sollte aus Performancegründen so klein

wie möglich, auf ein fachlich und technisch sinnvolles Mass begrenzt werden. Daten auf die

nicht mehr im täglichen Ablauf zugegriffen werden muss, werden im Datenlagerungssystem

langfristig gehalten und sind über geeignete Tools und Zugriffsmechanismen abrufbar.

Verbrauchssteu-

ersystem

Das Verbrauchssteuersystem deckt folgende Verbrauchssteuern und Lenkungsabgaben

ab:

Spirituosensteuer

Mineralölsteuer und Lenkungsabgaben

CO2-Abgaben

Tabaksteuer

Biersteuer



71/107


Das System besteht aus folgenden Komponenten:

Abgaben - beinhaltet die fachliche Funktionalität zur effizienten Prozessabwicklung im

Bereich Abgaben im Kontext von Grosskunden. Z.B. Mineralölkonzerne, Tabakkonzerne

Business-Rule-Management-System (BRM) - Entwicklung und den Einsatz einer auf Ge-

schäftsregeln basierenden fachlichen Anwendung. Geschäftsregeln werden als Service

bereitgestellt und zur Anwendung aufrufen.


von Geschäftsfäll- und Transportmitteldaten, sowie zur Übermittelung von Datenände-

rungen.










ten und Filtermöglichkeiten.


Prüfung auf Vollständigkeit und Schemakonformität von einkommenden Meldungen

werden auch die fachlichen Inhalte geprüft.

Verkehrsabgabe-

system

Das Verkehrsabgabensystem deckt den Bereich Schwerverkehrsabgaben (LSVA, PSVA)

und Vignetten ab und umfasst folgende Komponenten:

Abgaben - beinhaltet die fachliche Funktionalität zur effizienten Prozessabwicklung im

Bereich Schwerverkehrsabgaben und Vignetten.


von Geschäftsfäll- und Transportmitteldaten sowie zur Übermittelung von Datenänderun-

gen.










ten und Filtermöglichkeiten.


Prüfung auf Vollständigkeit und Schemakonformität von einkommenden Meldungen wer-

den auch die fachlichen Inhalte geprüft.



72/107


Fachanwendungen „Shared Services“

Beschwerdever-

waltung

Anwendung der EZV zur Behandlung von Kundenbeschwerden, die an die elektronische

Aktenführung/Dokumentenmanagement angebunden und in das Portal integrierbar ist.

Bewilligungsver-

waltung

Applikation zur Vergabe, Verwaltung, Überprüfung und Abschreibung von Bewilligungen

jeglicher Art. Ferner, wird die Applikation zur Vergabe, Entzug, Überprüfung und Abschrei-

bung von Kontingenten eingesetzt und ist in das Portal integrierbar.

BI-System EZV Anwendung zur systematischen Analyse (Auswertung und Darstellung) von Daten in

elektronischer Form zum Zweck der Erkenntnisgewinnung, um in Bezug auf die Unterneh-

mensziele bessere operative oder strategische Entscheidungen zu ermöglichen. Das spezi-

elle Augenmerk gilt, u.a., der Risikoanalyse und der Kundenbewertung sowie im Erstellen

von Statistiken (z.B. Aussenhandelsstatistik).

Datawarehouse Anwendung in der Daten aus unterschiedlichen Quellen in einem einheitlichen Format zu-

sammengefasst werden (Informationsintegration). Dadurch verbessert sich der Komfort

beim Zugang zu diesen Daten. Die Daten werden von den Datenquellen bereitgestellt und

im Extract, Transform, Load (ETL)-Prozess in das Data-Warehouse geladen und dort vor

allem für die Datenanalyse und zur betriebswirtschaftlichen Entscheidungshilfe in Unterneh-

men sowie zum Data-Mining langfristig gespeichert. ETL-Prozessschritte: 1) Extraktion der

relevanten Daten aus verschiedenen Quellen

Dokumentenma-

nagementsystem

(DMS)

Das Dokumentenmanagementsystem verfügt über Repository Services zum Erfassen,

Speichern, Verwalten, Recherchieren, Bearbeiten und Publizieren von Dokumenten des

Unternehmens. Das DMS besteht normalerweise aus den Komponenten Authoring, Work-

flow, Authentifizierung, Versionskontrolle, Check-In/Check-Out, Archivierung, Übersetzung

und Publishing. Diese Funktionalitäten müssen in einem DMS harmonisch zusammenarbei-

ten, nahtlos auf der bestehenden IT-Infrastruktur aufsetzen und ohne Medienbrüche umge-

setzt werden.

Einsatzleitsystem Das Einsatzleitsystem hat die Aufgaben: Kurzfristige / ad hoc Ressourcenplanung der Ein-

satzmittel und Einsätze, geografische Aufbereitung von Daten aus unterschiedlichen Kanä-

len und Quellen, Anbindung von unterschiedlichen Kommunikationsmitteln (Telefonie, UCC,

Funk), Journalführung, Unterstützung der Alarmierung, Einsatz Rapportierung. Ferner sol-

len die Journaldaten in andere Anwendungen (z.B. Kontrollsystem nach Rapportierung, GE-

VER etc.) automatisch übernommen werden.

Einsatzplanungs-

system

Anwendung zur mittel- bis langfristigen Ressourcenplanung (Personal, Material), sowie zur

Einsatz-Rapportierung, z.B., aufgrund von Lagebeurteilungen. Die Anwendung soll auch

mobil genutzt werden können.

Electronic Opera-

tion Register

(EMK)

Applikation zur Steuerung von Feingehaltsanalysen von Edelmetallen, zur Steuerung von

Edelmetallwarenstempelung (Punzierung) und zur Verwaltung von Bewilligungen und Ver-

antwortlichkeitsmarken im Bereich Edelmetalle (Zertifizierung von Edelmetallwaren).

Finanzverwal-

tungssystem

System zur Verwaltung der Finanzströme des Unternehmens, welches, u.a., folgende Auf-

gaben umfasst: Sicherheiten verwalten. Beträge einfordern, Rückerstattungen zuweisen,

Kreditoren- und Debitorenbuchhaltung vornehmen, Rechnungsstellung vornehmen, Ein-

und Auszahlung verwalten. Bestandskonten und Erfolgskonten führen, Entlastungen auf

Abgaben leisten, Mahnverfahren definieren und ausführen, Inkasso-Forderungen an die



73/107


Zentralen Inkassostelle (EFV) weiterleiten, Bargeldhinterlagen verwalten, Kassenzahlungen

und Online-Zahlungen leisten, Kassenabschluss und Ablieferung unterstützen.

GEVER-System Das GEVER-System dient der systematischen Kontrolle und Durchführung der Erstellung,

Entgegennahme, Aufbewahrung, Nutzung und Aussonderung von elektronischen Doku-

menten, einschliesslich der Vorgänge zur Erfassung und Aufbewahrung von Nachweisen

und Informationen über Geschäftsabläufe und Transaktionen in Form von Akten. Das GE-

VER-System unterstützt den GEVER-Standard, welcher den Einsatz von IKT-Mitteln für die

elektronische Geschäftsverwaltung definiert.

Issue Tracking

System

Anwendung zur Handhabung von Empfang, Bestätigung, Klassifizierung und Bearbeitung

von Kundenanfragen (Tickets bzw. Fälle). Als Anfragen werden direkte Kundenanfragen

oder -Anrufe, E-Mails, Ereignisse, usw. betrachtet. Das System bietet die Möglichkeiten der

Zuweisung eines Tickets an eine Organisationseinheit (auch direkt an Personen) zur weite-

ren Bearbeitung bis zur Lösung (closed ticket). Mit dem Issue Tracking System soll sicher-

gestellt werden, dass keine Nachricht verloren geht und jederzeit ein Gesamtüberblick über

die zu bearbeitenden Vorgänge möglich ist.

Befund- und Er-

eignisrapportie-

rungssystem

Querschnittsanwendung für die Bereiche Warenverkehr, Abgaben und Personenverkehr.

Umfasst folgende Komponenten:

Eigentliche Kontrollverwaltung - Selektion ausführen Kontrollbefund dokumentieren, be-

schlagnahmte Ware verwalten.

Ereignisverwaltung - Erfassen und Verwalten von Rapporten im Bereich des Personen-

verkehrs.

Warenkontrolle, inkl. Warenkontrollwerkzeuge materielle Kontrolle planen, vorbereiten

und durchführen.

Kundenverwal-

tungssystem

Zentrales System zum Verwalten und Bereitstellen von Kundendaten inkl. Transportmittel.

Dazu gehören, u.a., Rolle, Kontakt, Benutzer. Das System bietet auch Services zur Daten-

pflege durch die Kunden selber (Customer Self Services).

Laborinformati-

onssystem (LIMS)

Anwendung zur Messwerterfassung (Messgeräte, Aufnahme und Speicherung der Mess-

werte aus Sensoren. usw.), Messwertauswertung (mathematische Verarbeitung und Aus-

wertung der Messdaten, Probenmanagement, Abrechnung usw.) und zum Dokumentieren

von Experimenten, Forschungen und Prozeduren im Labor (Electronic Lab Notebook).

Sachanlagever-

waltungssystem

Querschnittsanwendung zur Sachanlagenverwaltung, die folgende Funktionen unterstützt:

Inventar führen (Material, Fahrzeuge, IKT etc.)

Material und Fahrzeuge bewirtschaften (inkl. Beschaffen, verkaufen, investieren, etc.).

Stammdatenver-

waltung (MDM)

Das MDM-System stellt eine übergreifende Instanz der Stammdatenverwaltung dar und

schafft so eine zentrale betriebliche Referenzdatenbasis (System of Record). Es umfasst

alle Stammdatenobjekte eines Unternehmens. Die Stammdatenverwaltung besteht aus ei-

ner Zusammenstellung von Prozessen, Richtlinien, Dienstleistungen und Technologien die

verwendet werden, um betriebliche Daten zu erstellen, zu pflegen, zu vereinheitlichen und

zu verwalten, welche mit dem operativen Kerngeschäft eines Unternehmens verbunden

sind.

Strafverfahrens- Querschnittsanwendung zur Behandlung von Strafverfahren und Administrativmassnah-



74/107


verwaltungs-Sys-

tem

men, zur Unterstützung von Analysen/Recherchen bei Vorermittlungen, sowie zum Veran-

lassen von Fahndungen oder Überwachungen.

Warenbuchhal-

tungssystem

Das Warenbuchhaltungssystem umfasst:

Verwaltung von Warenkonten und Warenbewegungen

Warenbewegungen kontrollieren / Vergleiche durchführen

Verlust/Gewinn-Kontrolle der Lagerbestände aufgrund von periodischen Bestandsmel-

dungen, sowie die Kontrolle der Rohmaterialverwendung

Zollregister Querschnittsanwendung zum Führen und Bereitstellen/Publizieren von Internetverzeichnis-

sen, in welchem bestimmte Informationen zu Kunden (z.B. Information über Tätigkeit, Be-

willigungen, etc.) für eine definierte Zielgruppe einsehbar sind. Folgende Ausprägungen ei-

nes Verzeichnisses sind vorgesehen: 1) Öffentliches Verzeichnis (Zielgruppe = Öffentlich-

keit), 2) Halb-öffentliches Verzeichnis (Zielgruppe = bestehender Kundenkreis) , 3) Internes

Verzeichnis (Zielgruppe = Mitarbeiter EZV)

Übergreifende Anwendungen

Workflow Anwendung für das Management und die Ausführung modellierter Arbeitsabläufe

(Workflows) auf der Basis eines Workflow-Management-Systems. Die Anwendung enthält

eine Komponente zur grafischen Modellierung der Arbeitsabläufe, sowie eine Komponente

zur Ausführung der modellierten Arbeitsabläufe.

Enterprise Archi-

tecture Modelling

(EAM)

Managementprozess, der im engeren Sinne die Koordination zw. IT-Bereich und Geschäfts-

bereichen herbeiführt. Enterprise Application Management steuert und managt den Prozess

der Gestaltung der Anwendungslandschaft vom aktuellen IST zur Ziel-Anwendungsland-

schaft. Dazu werden Projekte ins Leben gerufen, die wiederum durch die eigentlichen Ge-

schäftsbereiche verantwortet werden.

Für das EAM werden bei EZV die SIP, bzw. die TOGAF Methodik und Framework einge-

setzt.

Zugangs Kanäle

Input-/Output Ma-

nagement

Das Input-Management wird hauptsächlich zum Bereitstellen von eingescannten Input-Da-

ten, einschliesslich der Übermittlung an die entsprechenden Applikationen eingesetzt. Im

weiteren Sinne werden im Input Management strukturierte oder unstrukturierte Daten aus

verschiedenen Quellen elektronisch erfasst, um diese für die Weiterverarbeitung in Applika-

tionen bereitzustellen. Das Output Management dient der Erstellung, Generierung, Steue-

rung und Verteilung von elektronischen oder physisch vorliegenden Dokumenten an alle

vorgesehenen Empfänger im Unternehmen oder ausserhalb des Unternehmens.

CMS Anwendung zur Erstellung, Bearbeitung und Organisation von Inhalten (Content) zumeist in

Webseiten, aber auch in anderen Medienformen. Diese können aus Text- und Multimedia-

Dokumenten bestehen. Ein Autor mit Zugriffsrechten soll ein Content Management System

ohne HTML-Kenntnisse bedienen können. Besonderer Wert wird beim Content Manage-

ment auf eine medienneutrale Datenhaltung gelegt. So kann ein Inhalt auf Wunsch bei-

spielsweise als PDF- oder als HTML-Dokument abrufbar sein

Portal Der Anwendungskomplex Portal umfasst folgende Komponenten:

Suchmaschine zur Unterstützung der computergestützten inhaltsorientierten Suche in



75/107


elektronischen Datenbeständen des Unternehmens.

Portal zum zentralen Zugriff auf die Anwendungen der EZV über eine einheitliche Platt-

form. Eine manuelle Anmeldung an den in das Portal integrierten Anwendungen ist durch

Single-Sign-On nicht mehr notwendig, es gibt einen zentralen Zugriff über eine homo-

gene Benutzungsoberfläche.

In der Komponente Benutzerverwaltung werden die Benutzer eines Systems verwaltet.

Zu jedem Benutzer werden Identitätsmerkmale (z.B. Username, Passwort), sowie Kon-

taktinformationen (z.B. eMail, Mobilenummer) geführt. Jedem Benutzer werden Benut-

zerrollen zugewiesen. Diese sind im Kontext des Kunden für den der Benutzer aktiv ist

zu definieren.

Die Komponenten Wissensmanagement bildet die Integrationslogik mit dem Content Ma-

nagement System, dem Portal und der Suchmaschine ab.

Fat Client Fat Client bezeichnet vollwertig ausgestattete, leistungsfähige Computer mit ausreichender

Rechenkapazität, Plattenspeicher, Laufwerken, sowie leistungsstarken Grafikkarten.

Thin Client Das Gegenteil von Fat Client. Ein lediglich mit einem Mini-Betriebssystem ausgestatteter

Computer, welcher in der Regel nur aus einer Tastatur und einem Bildschirm besteht. Alle

Daten und Anwendungen sind zentral auf Servern gespeichert.

Mobile Client Grundsätzlich bezeichnet es einen Computer, welcher auf Mobilgeräten, wie Smartphones,

Sub-Notebooks, PDAs oder Tablets läuft. Ein mobiler Client wird, in der Regel, analog zum

Thin Client ausgestattet. Mit Ausnahme der GUI, läuft der Hauptteil der Anwendungen auf

den Backend-Systemen.

Komponenten der Integration

B2B-System Das B2B-System dient dem Austausch von Informationen und Services zwischen den EZV-

IT-Systemen und den Kunden- und Partner-IT-Systemen. Das B2B-System enthält eine

reine B2B-Komponente für die Feinautorisierung eines Partnersystems. Definition der unter-

stützten Kommunikationsprotokolle, Serviceeigenschaften (synchron, asynchron, wiederhol-

bar), sowie der Routing-Regeln. Im B2B-System sind auch die Komponenten zum Abonnie-

ren von Statusinformationen der relevanten Geschäftsfälle, sowie zur Verfügbarmachung

von öffentlichen Daten im Besitz der EZV angesiedelt.

Enterprise Ser-

vice Bus (ESB)

Technische Anwendung, die dem Austausch von Daten zwischen den (Fach)Anwendungen

im Sinne einer losen Kopplung dient. Das ESB-System unterstützt das Routing und Trans-

formation von Daten und ist in der Lage, Umsysteme über unterschiedliche Protokolle und

mittels vorgefertigter Bausteine einzubinden. Der Umgang mit Verschlüsselung wird jeden-

falls vorausgesetzt. Der Datenaustausch mit Sicherheitsorganen wird ebenfalls unterstützt.

Integrationsmoni-

tor System

Das System für das fachliche Monitoring der Date- und Informationsströme. Jeder Daten-

austausch, der aus mehreren untergeordneten Nachrichtenübermittlungen bestehen kann,

wird über fachliche Schlüssel identifiziert. Z.B., ist der Integrations-Monitor in der Lage, fol-

gende Fragestellung zu beantworten: "wann wurde die Verfügung XYZ zur Fakturierung

freigegeben".

Komponenten der IT-Sicherheit

IAM Standardanwendung des ISB und BIT. Übernimmt die Authentifizierung und Grobautorisie-

rung der eGov Benutzer. Beinhaltet auch eine Selbstregistration und Selbstadministration

https://de.wikipedia.org/wiki/Desktop-Computer

https://de.wikipedia.org/wiki/Smartphone

https://de.wikipedia.org/wiki/Sub-Notebook

https://de.wikipedia.org/wiki/Personal_Digital_Assistant

https://de.wikipedia.org/wiki/Tablet-Computer



76/107


für den eGov Benutzer. Abgrenzung Fachanwendung / IAM:

IAM stellt Identitäten bereit, während eine Fachanwendung sie anwendet.

IAM verwaltet die Rollen, während eine Fachanwendung sie bereitstellt.

IAM ist für Grobautorisierung zuständig (Fachrollen, die Berechtigungen in Anwendungs-

übergreifenden Prozessen zusammenfassen). Fachanwendung ist für Feinautorisierung

zuständig (Feinautorisierung: Vergabe der feingranularen Berechtigungen auf Objekte,

Komponenten und Daten).

PEP (Policy En-

forcement Point)

Anwendung zum sicheren Zugriff aus einem öffentlichen Netz auf Dienste im Unterneh-

mensnetzwerk. Normalerweise wird der Benutzer oder das System nur dann den Zugriff auf

die Dienste erhalten, wenn er authentifiziert und dazu autorisiert ist. Um die Sicherheit ge-

währleisten zu können, wird die Verwendung der Zugriffsprotokolle eingeschränkt und über-

wacht. Angriffe auf die Dienste im Firmennetzwerk werden durch PEP erkannt und verhin-

dert. Neben der Partnerauthentisierung und der Zugriffsüberwachung, gehört auch die

Transportverschlüsselung zu den Aufgaben von PEP.

Benutzer- und Zu-

griffsverwaltung

Mittels Benutzerregistrierung werden die Benutzer in das zentrale Benutzerverzeichnis ein-getragen, einschliesslich der Grobberechtigung.

Es wird zwischen internen und externen Benutzern unterschieden. Nachdem ein externer

Benutzer registriert ist, kann er über ein Berechtigungsverfahren einem Kunden zugeordnet

werden. Ein externer Benutzer kann unterschiedlichen Kunden zugeordnet werden, welche

von unterschiedlichen Fachbereichen verwendet werden.

Mobile Device

Management

Zentralisierte Verwaltung von Mobilgeräten, wie Smartphones, Sub-Notebooks, PDAs oder

Tablet-Computer durch einen oder mehrere Administratoren mit Hilfe von Software. Die

Verwaltung bezieht sich auf die Inventarisierung, die Software- und Datenverteilung, sowie

den Schutz der Daten auf den mobilen Geräten.

Zertifikatsverwal-

tung

(Public Key Infra-

structure)

Ist ein System, das digitale Zertifikate ausstellen, verteilen und prüfen kann.

Die Zertifikatsverwaltung wird genutzt, um das gesamten LifeCycle eines Zertifikats zu ver-

walten.

Komponenten der Basisdienste und Infrastruktur

Archivierung Die Archivierung digitaler Unterlagen im Bundesarchiv. Die Archivierung beruht auf folgen-

den Ansätzen:

Entkoppelung der Daten von spezifischen IT-Umgebungen

offene, standardisierte, generische Umgebungen

homogene Speicherinfrastruktur

wenige archivtaugliche Dateiformate

Migrationsverfahren

Büroautomation Anwendungen für den Software-Arbeitsplatz, welche sich auf dem Endsystem befinden.

Gemäss "Büroautomation Bund (BA Strategie)" sind diese Komponenten so genannten

Schalen zugewiesen. Unter Büroautomation fallen auch Office Anwendungen, sowie An-

wendungen zum File-Sharing,

E-Mail Das E-Mail-System hat die Aufgabe, E-Mails zu empfangen, zu versenden, zu speichern

und weiterzuleiten. Der eingesetzte Mailserver muss zwingend PKI Zertifikate unterstützen.

https://de.wikipedia.org/wiki/Smartphone

https://de.wikipedia.org/wiki/Sub-Notebook

https://de.wikipedia.org/wiki/Personal_Digital_Assistant

https://de.wikipedia.org/wiki/Tablet-Computer

https://de.wikipedia.org/wiki/Systemadministrator

https://de.wikipedia.org/wiki/Digitales_Zertifikat



77/107


Der Datenaustausch mit Sicherheitsorganen wird ebenfalls unterstützt.

Netzwerkdienste Zusammensetzung mehrerer Komponenten im Netzwerk

DNS-Services: Übersetzungsdienst zwischen Rechnername (hostname) und IP-Ad-

resse.

Dynamic Host Configuration Protocol (DHCP) Verwaltung der TCP/IP-Konfigurationen

Network Time Protokoll (NTP) – Synchronisation von Uhren in Computersystemen über

ein Netzwerk.

Load Balancer – wird eingesetzt zur Verteilung von grossen Mengen von Anfragen und

von unternehmenskritischen Applikationen auf mehrere Server und zum Schutz vom

Totalausfall.

Managed Print Services – Einsatz von gemanagten Netzwerkdruckern.

Sprachkommuni-

kationsdienste

Sprachkommunikation und Unified Communication & Collaboration (UCC) ist ein zukunfts-

orientierter ISB Standard für die Integration von Sprachkommunikation, Mail, Videokonfe-

renz, Funktionalitäten zur Zusammenarbeit sowie gemeinsamen Ablagen. Hierfür werden

die traditionelle Telefonie (Sprachnetz), Voice-Over-IP und Mobilfunk auf einer Plattform

vereint.

VDI

(Virtuelle Desktop

Infrastruktur)

Es handelt sich um eine Technologie, bei welcher komplette PC-Desktops auf den Servern

im Rechenzentrum virtualisiert werden. Statt auf jedem PC lokal das Betriebssystem und

die Anwendungen zu installieren, befinden sich diese zentral auf den Servern im Rechen-

zentrum.

Tabelle 26: Anwendungen

4.2.4.4 IT-Funktionen pro Anwendung

Aufbauend auf der erarbeiteten Bündelung der IT-Funktionen pro Anwendung muss die detaillierte funk-

tionale Ausgestaltung der Fachanwendungen, fachbezogenen technischen Komponenten und Zugangs-

kanäle im Rahmen der Umsetzungsprojekte konkretisiert werden. Die nachfolgende Abbildung zeigt eine

Übersicht aller IT-Funktionen pro Fachanwendung und technischer Komponente.

Eine detaillierte Auflistung der Funktionen der aufgeführten Clients und der Komponenten der Bereiche

Basisdienste und IT-Sicherheit wurde nicht modelliert, deshalb fehlen diese Komponenten in der Über-

sicht.



78/107

Abbildung 24 - IT-Funktionen pro Anwendung



79/107

4.2.5 Vorgaben zur Informatiksicherheit für B2B und Portal

Die Einführung einer B2B Komponente und eines Portals zieht dedizierte Anforderungen an die Informa-

tiksicherheit nach sich. Diese werden nachfolgend beschrieben.

Beim Interface für die Kommunikation von Business zu Business (B2B) und des Portals (B2B/Portal)

handelt es sich um die zentrale Anlaufstelle für alle Partner und Kunden der Zollverwaltung. Hier fallen

alle Arten von mehrheitlich schutzwürdigen Daten an. Die verschiedenen Ansprüche der Nutzer an die

Verwendung des B2B/Portals führen zudem zu unterschiedlichen Ausgestaltungen hinsichtlich der Inter-

aktivität, Benutzbarkeit und der erwarteten Sicherheitsniveaus.

Die IKT-Sicherheit und der Informations- und Datenschutz sind zentrale Elemente bei der Umsetzung

des Interfaces für die Kommunikation von Business zu Business (B2B) und des Portals.

Als Schaufenster der Zollverwaltung muss diese Infrastruktur besonders hohen Anforderungen betreffen

Verfügbarkeit, Vertraulichkeit und Nachvollziehbarkeit genügen.

4.2.5.1 Vorgaben an die technische Umsetzung

Das Portal / Interface für die Kommunikation von Business zu Business (B2B) muss fähig sein, unter-

schiedliche Anforderungen an den Schutz der Anwender und deren Daten zu erfüllen. Als Grundlage

muss vorgängig durch das Geschäft aufgezeigt werden, welchen Schutzbedarf für die unterschiedlichen

Verwendungen (z.B. interaktive Kommunikation in Web Foren, Deklarationsmasken für unterschiedlich

Fachanwendungen, Abfrage- und Suchfunktionen für Informationen und Daten, Zugang mit Smart De-

vices) besteht. Anhand dieser Angaben muss das Portal unterschiedliche Schutzstufen zulassen kön-

nen, z.B. Grundschutz für Foren/Chat/Zoll-Community, erweiterte Schutzfunktionen für Abfragen und

einfache Deklarationen, hoher Schutz für die Übermittlung von sensitiven Daten.

- Verbindungen, welche Kundendaten (auch nicht dem DSG unterstehende Daten wie z.B. Ge-

schäftsgeheimnisse) enthalten, müssen zwingend mit einem aktuell sicheren Verfahren ver-

schlüsselt werden. Es soll geprüft werden, ob das Webportal generell verschlüsselt werden kann,

wie dies heute bereits bei z.B. Google und Bankenverbindungen gemacht wird.

- Um eine zusätzliche unabhängige Sicherungsschicht auf einer entkoppelten Infrastruktur zu er-

halten muss das Portal hinter einem Web Application Firewall (WAF) stehen.

- Die Verfügbarkeit aller verwendeten Komponenten ist auf die, durch das Business geforderte,

Verfügbarkeit abgestimmt, so dass sowohl die Wirtschaftlichkeit gegeben ist wie auch die Verfüg-

barkeit nicht durch einen Single Point of Failure gefährdet wird.

- Das Portal ist resistent gegen Angriffe auf die Verfügbarkeit (Denial of Service Attacken).

- Es dürfen keine Kundendaten auf dem Webserver mit dem Portal gelagert oder zwischengespei-

chert. Dies bedeutet, dass eine 3-Tier-Architektur (Client <-> Portal <-> Datenbank) umgesetzt

werden muss.

- Zum Schutz der Infrastruktur muss verhindert werden, dass unautorisierte Zugriffe erfolgen oder

Schadsoftware, z.B. beim Versand von Dokumenten, übermittelt wird. Hierzu müssen die Einga-

ben auf ihre Korrektheit und Sicherheit überprüft (input validierung, z.B. Prüfung ob die eingege-

bene Information die notwendige Syntax aufweist) oder korrigiert (input sanitization, z.B. Prüfung

von Dokumenten mittels eines Malwareschutzprogramms) werden. Hierzu soll zum Beispiel der

Einsatz einer Datenbank-Firewall geprüft werden.



80/107

- Alle Tätigkeiten auf dem Portal müssen geloggt und die Logfiles auf einem separaten System ab-

gelegt (separation of duty) werden. Dies gilt sowohl für Benutzeraktivitäten wie auch für Tätigkei-

ten der Administratoren.

- Das Portal muss permanent mit einem Integritätscheck auf nicht autorisierte Änderungen über-

prüft (Verhinderung eines defacement des Webauftritts) werden.

4.2.5.2 IKT-Sicherheitsgrundlagen

Das Portal / Interface für die Kommunikation von Business zu Business (B2B) muss alle bestehenden

Vorgaben betreffend der IKT-Sicherheit und dem Informationsschutz erfüllen. Zudem gilt es jeweils die

bewährtesten Methoden (best practices) umzusetzen. Diese Anforderungen sind grossmehrheitlich mit-

tels organisatorischer Massnahmen vorzugeben und zu prüfen. Verantwortlich für die Umsetzung und

Prüfung der Vorgaben sind sowohl der Leistungserbringer wie auch der Leistungsbezüger, sprich die

Zollverwaltung. Die Verantwortlichkeiten müssen verbindlich geregelt und vertraglich festgehalten sein.

- Für alle kryptografischen Funktionen (Verschlüsselung, Authentisierung, Integritätsprüfung, Sig-

natur etc.) müssen die offiziellen Zertifikaten der Swiss-Gov-CA (Admin PKI) eingesetzt werden.

Dies dient als vertrauensbildende Massnahme für die Benutzer des Portals.

- Die Entwickler des Webportals müssen bestätigen, dass sie nach den Sicherheitsvorgaben von

Open Web Application Security Project (OWASP) entwickeln.

- Die Webanwendungen (B2B/Portal) müssen regelmässig mittels geeigneten Methoden auf Si-

cherheitslücken getestet (Webapplication Vulnerability Assessment) werden. Vorgehenspläne

müssen sicherstellen, dass gefunden Sicherheitslücken innerhalb der notwenigen Zeit nach vor-

gegebenen Prozessen geschlossen werden oder sichernde Massnahmen ergriffen werden kön-

nen.

- Die für die Sicherheit relevanten Dokumente (SchubAn, ISDS-Konzept, Notfallplan, OHB, BHB,

Benutzer-/Rollenkonzept) müssen nach deren Erstellung regelmässig auf ihre Gültigkeit geprüft

und aktuell nachgeführt werden.

- Der Grundschutz nach WIsB muss durch alle an der Infrastruktur beteiligten Komponenten einge-

halten werden.

- Die Vorgaben zu den verwendeten Netzzonen müssen uneingeschränkt eingehalten werden.

- Für alle auf dem Portal verarbeiteten Daten muss der Datenherr bekannt und für alle Anwendun-

gen müssen die zuständigen Verantwortlichen bekannt sein. Die Administratoren des Portals, so-

wohl für die technische Infrastruktur wie für die Inhalte, müssen namentlich bekannt und Sicher-

heitsüberprüft (mind. PSP 10) sein.

- Das Portal ist das Schaufenster der Zollverwaltung. Daher sollen Veröffentlichungen von Beiträ-

gen und Information gemäss dem Vieraugen-Prinzip freigegeben werden. Interaktive Inhalte (z.B.

Chat, Zoll-Community, Supportanfragen, Infoaustausch) sollen, wo durch Dritte einsehbar, mode-

riert werden.



81/107

4.2.5.3 Sprachgebrauch

MÜSSEN, SOLLEN, DÜRFEN richtet sich nach dem Glossar14 des BIT.

4.3 Technologiearchitektur

Die Technologiearchitektur setzt sich aus zahlreichen Bausteinen zusammen, die wiederum aus einer

Vielzahl verschiedenartige Software- und Hardware-Komponenten abgebildet sein können. Diese Bau-

steine sind in der Regel, mit Ausnahme der Benutzeroberflächen, für den Fachanwender nicht sichtbar.

Für die Auswahl der Bausteine ist eine breitgefächerte Anzahl unterschiedlicher Einflussfaktoren rele-

vant. Sie reichen von der Respektierung allgemeiner Prinzipien über allgemeine und bausteinbezogene

Kriterien bis hin zu einer möglichst einfachen, kostengünstigen Umsetzbarkeit und Betreibbarkeit. Dabei

muss die bestehende IT-Landschaft der EZV in die Betrachtungen aufgenommen und hinsichtlich

Integrierbarkeit und Migrationsfähigkeit beurteilt werden.

Die jeweils erforderlichen technischen Design-Entscheidungen können erst im Rahmen von konkreten

Umsetzungsprojekten getroffen werden. So wird bei Kaufprodukten oder Standardprodukten die

unterliegende technologische Architektur durch den Lieferanten vorgegegben. Aus diesen Gründen wird

im Rahmen der GAR-EZV Studie der Fokus auf die übergreifenden und allgemein gültigen

Anforderungen, Prinzipien und Abhängigekeiten gelegt.

4.3.1 Prinzipien

Die nachfolgenden Prinzipien haben für alle technologischen Komponenten und Bausteinen Gültigkeit

und müssen bei Entwicklung und Beschaffung berücksichtigt werden.

Prinzip T1 Technologiestandards

Aussage Die Technologiestandards des ISB und des BIT sind bei der Entwicklung und Beschaffung von

Anwendungen einzuhalten.

Begründung

Die BIT Standards sind konform zu den ISB Standards und auf den Betrieb von Anwendun-

gen abgestimmt.

Die Benutzung und Einhaltung von Standards vereinfacht die Integration und Interoperabili-

tät von Anwendungen.

Die Wartbarkeit eines Systems erhöht sich, da keine proprietären bzw. hersteller- / lieferan-

tenabhängige Protokolle verwendet werden.

Auswirkung

Das Prinzip muss bei jeder Eigenentwicklung durchgesetzt werden.

Bei WTO-Vergaben sollen relevante ISB- und BIT-Standards berücksichtigt werden.

Existierende Anwendungen, die nicht konform sind mit den Standards, dürfen nicht weiter-

entwickelt werden.

Fokussierung auf Technologiestandards führt zu höheren Skalenerträgen im IT-Betrieb

Prinzip T1 – Technologiestandards

14 Quellle: http://intranet.bit.admin.ch/glossar/index.html?lang=de, Kundenplattform BIT



82/107

Prinzip T2 Technologie-Homogenität

Aussage Die technische Komponentenvielfalt ist durch Mehrfachverwendung sowie Einhaltung von

Standards zu beschränken. Die einzelnen Komponenten sollen aufeinander abgestimmt sein.

Begründung

Skaleneffekte in Entwicklung und Betrieb

Erhöhung der Wiederverwendbarkeit und gemeinsamen Nutzung von Infrastruktur

Kostenreduktion durch die Vermeidung von redundanten Investitionen in Technologiekom-

ponenten

Auswirkung

Das Architekturmanagement muss zwischen Leistungsbezüger (LB) und Leistungserbringer

(LE) abgestimmt sein

Technologische Design-Entscheidungen müssen mit den Architektur- und Roadmap Ver-

antwortlichen auf Seiten LB und LE abgestimmt sein.

Prinzip T2 – Technologie-Homogenität

Prinzip T3 Homogenisierung der Entwicklungsframeworks

Aussage Es sollen möglichst wenige Entwicklungsframeworks mit jeweils aufeinander abgestimmten

Komponenten genutzt werden.

Begründung

Entwicklungskosten durch stabile und weitverbreitete Frameworks senken.

Investitionskosten in das Entwicklungs- und Support Knowhow minimieren.

Erhöhung der Produktivität in der Entwicklung und ein verbessertes time-to-market.

Auswirkung

Die Anzahl der Entwicklungsframeworks wird auf zwei und höchstens drei Frameworks be-

schränkt.

Es werden nur Tools und Applikationen beschafft, die möglichst Framework neutral sind o-

der zumindest durch existierende Frameworks unterstützt werden können.

Vorhandenes Knowhow wird optimal eingesetzt und dadurch Entwicklungsressourcen ge-

spart.

Prinzip T3 – Homogenisierung der Entwicklungsframeworks

4.3.2 Anforderungskategorien

An die Technologie-Architektur bestehen vielfältige Anforderungen, die sich in verschiedene Kategorien

einteilen lassen. Grundlegend ist hier – im Einklang mit TOGAF – die Unterscheidung von funktionalen

und nichtfunktionalen Anforderungen.

Die funktionalen Anforderungen werden im Rahmen der Umsetzungsprojekte durch die detaillierte

Anforderungsanalyse erhoben. Zum jetzigen Zeitpunkt kann deshalb in diesem Bereich keine Aussage

gemacht werden.

In den nachfolgenden Kapiteln werden allgemein gültige, nichtfunktionale Anforderungen aufgeführt.

Diese müssen in den Projekten jeweils für die einzelnen Bausteine noch ergänzt werden. Dabei spielen

wirtschaftliche Betrachtungen eine gewichtige Rolle, da sich diese Anforderungen (z.B. Verfügbarkeit)

nicht nur auf die Technologie sondern auch auf den Betieb und dessen Organisation auswirkt. Die nicht-

funktionalen Anforderung finden in der Regel in den Service Level Agreements, die zwischen dem Leis-

tungsbezüger (EZV) und dem Leistungserbringer (typischerweise BIT) bestehen, ihren Niederschlag.

Die im Projekt Fracht Redesign in der Phase Technologiearchitektur [FrachtTA] erhobenen Anfor-

derungen an Technologie-Komponenten und –Bausteinen sind allgemein gültig und werden hier

inhaltlich übernommen.



83/107

4.3.2.1 Allgemeine Anforderungen an Technologie-Komponente und -Bausteine

In der nachfolgenden Tabelle sind die allgemeinen Anforderungen an Technologie-Komponente und

Bausteine aufgeführt. Diese Anforderungen betreffen zum einen die technische Beschaffenheit und zum

anderen die Service-Qualität, mit der sie bereitgestellt und genutzt werden können.

# Stichwörter Anforderung

AA.1 Dokumentation

Es sind Technologie-Komponenten einzusetzen, deren Aufbau, Schnitt-

stellen, Konfigurations- und Weiterentwicklungsmöglichkeiten sowie Be-

triebsverhalten möglichst umfassend und verständlich dokumentiert ist.

AA.2 Know-how

Es sind Technologie-Komponenten einzusetzen, für die je nach Anwen-

dungsgebiet, beim Leistungserbringer und/oder auf dem Markt dauerhaft

(ca. 10 Jahre) ausreichend grosses Know-how verfügbar ist.

AA.3 Beschaffbarkeit

Es sind Technologie-Komponenten einzusetzen, die im Rahmen des ge-

planten Nutzungshorizonts in geeigneter Weise, insbesondere über

rechtskonforme Wege und zu vorhersehbaren Konditionen, beschafft

werden können.

AA.4 Hersteller-

Unterstützung

Es sind Technologie-Komponenten einzusetzen, für die von Seiten ihrer

Hersteller möglichst langfristige Unterstützung zu erwarten ist (Patches,

Security Fixes, Support-Leistungen).

AA.5 Fortschrittlicher

Aufbau

Es sind Technologie-Komponenten einzusetzen, deren Aufbau moder-

nen, möglichst allgemein anerkannten Standards genügt.

AA.6 Moderne

Schnittstellen

Es sind Technologie-Komponenten einzusetzen, die über moderne

Schnittstellen verfügen und eine möglichst weitgehende Interoperabilität

mit anderen Komponenten, Anwendungen oder Services erlauben.

AA.7 Flexibilität Technologische Bausteine sind so zu formen, dass sie sich in möglichst

flexibler Weise weiterentwickeln lassen.

AA.8 Wartbarkeit

Technologie-Bausteine müssen so beschaffen sein, dass sie innerhalb

der angemessenen Intervalle gewartet werden können, ohne dabei ver-

einbarte Service Levels zu verletzen.

AA.9 Portabilität

Technologie-Bausteine müssen so beschaffen sein, dass die auf ihnen

beruhenden Anwendungen, Daten und Services möglichst flexibel por-

tiert werden können.

AA.10 State-of-the-art

Wo für Anwendungen, Daten oder Services erforderlich, sind Technolo-

gie-Bausteine state-of-the-art zu gestalten, etwa unter Nutzung bewähr-

ter Techniken wie Clustering, Datenspiegelung und Virtualisierung.



84/107


AA.11 Leistungsfähigkeit

Technologie-Bausteine müssen so beschaffen sein, dass sie bedarfsge-

rechte Abstufungen der Leistungsfähigkeit (in Bezug auf Antwortzeitver-

halten, Datendurchsatz etc.) erlauben.

AA.12 Cloud-Eigenschaf-

ten

Wo zweckmässig, sind Technologie-Bausteine derart zu gestalten, dass

sie in Form typischer Cloud-Merkmale bereitgestellt werden können.

Diese Merkmale sind:

Elastizität ("nur nutzen, was man braucht")

"Pay per use" ("Nur zahlen, was man nutzt")

Skalierbarkeit (horizontal und vertikal)

Self Service (Anpassung durch Leistungsbezüger)

Agilität (Schnelle Anpassbarkeit)

AA.13 Betriebskosten Die Technologie-Bausteine sind den Anforderungen entsprechend nach

wirtschaftlichen Kriterien zu bilden und zu betreiben.

Tabelle 27: Allgemeine Anforderungen an Technologie-Komponenten

4.3.2.2 Umsetzungsbezogene Anforderungen

Die untenstehende Tabelle führt die Anforderungen auf, die im Hinblick auf die Umsetzbarkeit der Zielar-

chitektur zu beachten sind.


AU.1 Migrationskosten

Bei der Definition der Zielarchitektur sind Migrationskosten zu berück-

sichtigen, die je nach Technologiewahl in Höhe und Tragbarkeit für die

EZV variieren können.

AU.2 Investitionsschutz

Bei der Definition der Zielarchitektur ist zu beachten, dass im Zuge ihrer

Umsetzung ungeplante Abschreibungen auf bestehenden Technologien

vermieden werden können.

AU.3 Bestehende Tech-

nologien

Bei der Definition der Zielarchitektur sind Technologie-Komponenten

und -Bausteine zu bevorzugen, deren Interoperabilität mit bestehenden

Technologien gesichert ist oder mit einem verhältnismässigen Aufwand

gesichert werden kann. Dadurch können Transformationsrisiken teil-

weise vermieden werden.

Tabelle 28: Umsetzungsbezogene Anforderungen



85/107

4.4 Technologie Referenzmodell

Um die Bausteine der Technologiearchitektur einheitlich einordnen zu können, empfiehlt es sich, ein Re-

ferenzmodell heranzuziehen. Eine zu diesem Zweck geeignete Taxonomie stellt die auf die Ansprüche

der Bundesverwaltung zugeschnittene Technologielandkarte15 des BIT [TechLK-BIT] dar. Um einen

möglichst hohen Wiedererkennungswert zu schaffen, wird dieses Referenzmodell auch im Kontext von

GAR-EZV und danach bei der konkreten Umsetzung der Projekte verwendet werden.

Für jeden Baustein in der Technologielandkarte existieren eine Vielzahl von technischen Produkten und

Komponenten auf dem Markt. Um Synergiepotential in der Entwicklung wie auch im Betrieb nutzen zu

können, werden sowohl vom ISB als auch vom BIT für die einzelnen Komponenten Standardlösungen

definiert. Die nachstehende Abbildung zeigt das Modell im Überblick.

Abbildung 25: Technologielandkarte BIT

Die Farben zeigen an, für welche Komponenten Standards definiert (grün), in Bearbeitung (gelb) oder

noch offen (rot) sind.

15 Die Technologielandkarte wird regelmässig auf dem aktuellem Stand im Kundenportal des BIT publiziert http://intranet.bit.ad-

min.ch/dokumentation/02687/02690/05124/index.html?lang=de



86/107

4.5 Abhängigkeiten

4.5.1 Anwendungen zu Technologie

Für die Festlegung einer Zielarchitektur auf der Technologiearchitekturebene muss eine Vielzahl von

Fragestellungen und Abhängigkeiten gegenüber der Applikationsarchitektur beachtet werden. Insbeson-

dere können die anwendungsspezifischen funktionalen und nicht-funktionalen Anforderungen einen ent-

scheidenden Einfluss auf die Auswahl und die Ausprägung der Technologiearchitektur haben.

Ein weiterer entscheidender Faktor ist die Frage, in wieweit Anwendungen der SOLL-Architektur am

Markt beschafft oder selbst entwickelt werden sollen. Gemäss IKT-Strategie [IKT-Strat-Bund] gilt das

Prinzip, dass Eigenentwicklung nur dort betrieben werden soll, wo am Markt keine bewährten Produkte

verfügbar sind. Die Tendenz wird bei der Mehrzahl der identifizierten Anwendungen hin zu Kaufproduk-

ten sein.

In der Regel haben Standard- bzw. Kaufprodukte auch technische Abhängigkeiten zur Folge, sodass die

Identifikation der benötigten technologischen Bausteine sowie deren technologische Umsetzung erst im

Kontext der konkreten Projekte sinnvoll sind.

4.5.2 Entwicklung und Betrieb

Die Ausprägung der technologischen Bausteine sowie deren nicht-funktionalen Anforderungen beein-

flussen massgeblich die Betriebsorganisation und im Falle von Eigenentwicklung auch den Entwick-

lungsbereich. Um Synergien und Skaleneffekte nutzen zu können, ist deshalb eine Einschränkung der

technologischen Vielfalt sowie die Nutzung von Standards unerlässlich. Um diese Fokussierung zu errei-

chen, hat das BIT basierend auf der Technologielandkarte die Produktionslinien definiert. Unter der An-

nahme, dass das BIT als Leistungserbringer zumindest die Rolle des Betreibers wahrnehmen wird, sind

diese Produktionslinien bei der Ausgestaltung der konkreten Projekte zu beachten. In der nachfolgenden

Abbildung sind die Produktionslinien inklusive der verwendeten Bausteine (gemäss Kapitel 2.1) darge-

stellt



87/107

ProduktionslinieJEE/WLS/Oracle

ProduktionslinieLAMP

ProduktionslinieJEE/WAS/Oracle

ProduktionslinieSAP/Oracle

Produktionslinie.NET/Oracle

Produktionslinie JSpring/Oracle

Produktionslinie.NET/SQL

Fachanwendung Fachanwendung

Applikationsserver OS

APPL

RTE PHP/PerlJava Spring Java EE

VM

HW

WebLogicTomcat NetWeaverWebSphere Apache

SLES

VMWare ESX

Intel x86

Datenbankserver

DBMS MSSQL MySQLOracle

OS Windows SLESAIX

VM

HW

VMWare ESX

Intel x86 pSeries Intel x86

.NET

IIS

Windows

VMWare ESXPowerVM

Speichersystem

InfrastrukturStrom

Klimatisierung

Raum

Netzwerk

Rack

SAN DASNAS

T1 T2 T3 T4 A1 A2 A5 A6 A7 A8

Zutrittskontrolle

Backupsystem Disk-to-Disk Disk-to-Tape

Fullservice

Hosting

Housing

Betrieb Fachanwendung – Layermodell

Abbildung 26: BIT Produktionslinien

Die sieben definierten Produktionslinien unterscheiden sich nicht nur auf technologischer Ebene sondern

auch bezüglich der Wertschöpfungstiefe des BIT Angebots.

Bei drei Produktionslinien tritt das BIT als Full Service Provider auf (.NET/SQL, Java Spring, SAP). Auf

diesen grünen Produktionslinien entwickelt, wartet, integriert und betreibt das BIT neue sowie beste-

hende Anwendungen und stellt dabei die personelle Kapazität sicher.

Auf weiteren vier gelben Produktionslinien integriert und betreibt das BIT, hat jedoch keine eigene Kapa-

zität für die Entwicklung und Wartung der Anwendungen. Es werden jedoch neue Anwendungen auf die-

ser Basis in Betrieb genommen.



88/107

5 Weitergehendes Potential der Architektur

Dieses Kapitel hat zum Zweck, das Potential der Architektur über die EZV hinaus aufzuzeigen. Es

sprengt damit grundsätzlich den Rahmen von GAR-EZV. Der kurze Exkurs soll im Zusammenhang mit

der Weisung über die Referenzarchitektur für Fachanwendungen im Eidgenössischen Finanzdeparte-

ment, welche zurzeit in Vernehmlassung ist, gesehen werden. Mit der Weisung werden EFD übergrei-

fende Prinzipien in den verschiedenen Architekturdomänen definiert, mit dem Ziel, definierte Geschäfts-

objekte und Funktionen einheitlich zu handhaben oder gar gemeinsam zu führen.

Die erarbeitete EZV Soll-Architektur hat durch ihre Modularität, die Integrationsschicht wie auch die kon-

sequente Entkopplung der Benutzerschnittstelle von der Fachanwendungslogik das Potential über die

EZV hinaus erweitert zu werden. Zu diesem Zwecke müsste mit den Ämtern mit welchen eine Zusam-

menarbeit angestrebt wird, auf der Ebene der Integration, des zentralen Zugangs und bei Teilen der Si-

cherheit ein einheitliches Vorgehen definiert und teilweise Daten gemeinsam genutzt werden.

…

IT-Sicherheit

IAM

Basisdienste

E-MailBüro-

automationSprachkom-munikation

Netzwerk-dienste

VDI Archivierung

Integration und Prozesssteuerung

Zentraler Zugang

Nationale Partner Internationale Partner Innere Sicherheit

Workflow

Führung & Unterstützung

ImmobilienBewirtschaftung

MitarbeiterAusbildung

PortfolioManagement

Integriertes Performance Management

Kunde EZV Mitarbeiter

Internet Intranet / BV Netz

Kunden-Anwendung

Partner-Anwendung

EnterpriseArchitectureManagement

…

PEP

Benutzer & Zugriffs-

verwaltung

Mobile Device Mgmt.

Zertifikats-verwaltung

PKI

Fat Client Thin ClientMobile Client

Enterprise Service Bus

B2BIntegrations-

Monitor

In-/OutputManagement

PortalCMS

Eidgenössisches Finanzdepartement

EZV ESTV BIT …

WBF

BLW …

SEC

O

EDI

BA

G …BfS

EJPD

… ……

…

… ……

Abbildung 27: Weitergehendes Potential der Architektur

Die folgenden 2 Beispiele zeigen die Möglichkeiten der Architektur auf:

Admin.ch Portal Der Kunde hat ein Login für Bundesangelegenheiten oder zumindest für

alle EFD Themen. Z.B. kann sich ein Landwirt einloggen und hätte über

das gemeinsame Portal Zugriff auf die Spirituosenversteuerung, die offe-

nen Treibstoffrückerstattungen sowie die Tier-Datenbank des BLW und

seine Steuererklärung der ESTV.

Dies würde von den beteiligten Ämtern mindestens die gemeinsame

Pflege der Benutzerverwaltung und der Kundenstammdaten erfordern.



89/107

Technologisch müssten die Bausteine IAM, Benutzer- & Zugriffsverwal-

tung (gemeinsamer Mandant), Enterprise Service Bus und das Portal ge-

meinsam genutzt und betrieben werden.

Datenaustausch

mit int. Behörden

Der Austausch von Daten mit internationalen Behörden erfolgt nach der

vorliegenden Architektur unter Nutzung der ESB und B2B Komponente.

Innerhalb des EFD haben sowohl die EZV als auch die ESTV die Anfor-

derung mit internationalen Partner Daten auszutauschen. Um Skalenef-

fekte bei Entwicklung, Wartung und Betrieb nutzen zu können, müssten

die beiden Lösungen harmonisiert und auf einer gemeinsamen Infrastruk-

tur oder aber zumindest mit der identischen Technologie umgesetzt wer-

den.

Als Grundsatz sollten bei der Umsetzung der konkreten Projekte jeweils für die nachfolgend aufgeführ-

ten Geschäftsobjekte und Anwendungen allfällige Synergien über den Fokus der EZV hinaus geprüft

werden.

Geschäftsobjekte Anwendung

Behörde

Benutzer

Bewilligung

Konto

Kunde

Rechnung

Sicherheiten

Portal

B2B

Enterprise Service Bus

In-/Output Management

Workflow

Identity & Access Management (IAM)

Benutzer- & Zugriffsverwaltung

Kundenverwaltung

Finanzverwaltung

GEVER

Tabelle 29: Übergreifendes Synergiepotential



90/107

6 Fazit

6.1 SOLL-Architektur GAR-EZV

Die SOLL-Architektur ermöglicht der EZV die Schaffung eines einheitlichen Datenmodells, welches zu

konsistenten und nicht redundanten Daten führen muss. Auswertungen auf Basis von geordneten und

durchgängigen Daten führen zu zuverlässigeren Ergebnissen, erlauben es Muster zu erkennen und er-

möglichen eine verbesserte Auswertung für z.B. die Risikoanalyse.

Die strukturiert gesammelten Daten unterstützen zudem das Open-Governement-Data Konzept.

Durch Fokussierung der Anwendungen auf Funktionen und Daten können Redundanzen vermieden wer-

den. Bei einer konsequenten Umsetzung führt dies zu weniger doppelten Daten und weniger Anwendun-

gen, was langfristig zu einer Reduktion der Komplexität der Architektur führt. Die Wiederverwendung von

Anwendungen in verschiedenen Bereichen schafft Synergien, welche zu Skaleneffekten und Kostenein-

sparungen führen können.

Die Schaffung eines EZV-weiten Portals wird den Kunden die Kommunikation mit den verschiedenen

Stellen der EZV erleichtern. Die Nutzung von B2B-Komponenten lässt den Einsatz von standardisieren

Schnittstellen zu, was den Datenaustausch vereinfacht. Die Ausrichtung auf Webtechnologien ermög-

licht zudem die mobile Nutzung der Anwendungen für Kunden aber auch für EZV-Mitarbeiter.

Mit einer modularen Struktur schafft die SOLL-Architektur mehr Flexibilität bei Anpassungen, womit

schlussendlich das Reagieren auf Anpassungen und neuen Trends vereinfacht und beschleunigt.



91/107

6.2 Übersicht über die SOLL-Architektur GAR-EZV

Abbildung 28: Übersicht über die SOLL-Architektur GAR-EZV



92/107

6.3 Weiteres Vorgehen

In einem nächsten Schritt wird die erstellte SOLL-Architektur mit der IST-Architektur verglichen und ana-

lysiert. Anhand einer GAP-Analyse werden die Lücken in der IKT der EZV aufgezeigt. Daraus können

Massnahmen abgeleitet werden, welche definieren, wie und in welchem Zeitraum die Lücken geschlos-

sen werden können. Dies ermöglicht eine grobe Übersicht über die zukünftigen IKT-Vorhaben der EZV

und deren Einfluss aufeinander. Dies ist unter anderem eine Voraussetzung für eine Aufwandschätzung.

Die Übersicht der Unternehmensarchitektur befähigt die EZV nach Abschluss der Studie den möglichen

Einfluss auf die bestehenden Prozesse abzuschätzen. Zusätzlich muss die EZV prüfen, ob und welchen

Einfluss die zukünftige Unternehmensarchitektur auf ihre Organisation hat.

Dazu müssen die SOLL-Geschäftseigenschaften in SOLL-Geschäftsfunktionen ausgearbeitet und an-

schliessend daraus die SOLL-Prozesse definiert werden. Dies ermöglicht der EZV eine Planung zu ma-

chen, wie und in welchem Zeitraum von den IST- zu den SOLL-Prozessen gewechselt werden soll.

Prozessänderungen bringen Änderungen in den Tätigkeiten und somit auch der Organisation mit sich.

Diese gilt es zu berücksichtigen.

Durch die alljährliche iterative Überprüfung der Unternehmensarchitektur (IST-Analyse und SOLL-De-

sign) wird sichergestellt, dass die Veränderungen und Erweiterungen in die gewünschte strategische

Richtung gehen.



93/107

7 Anhänge

7.1 Projektplan

Die Erarbeitung des Projektes folgt der Planung der nachstehenden Meilensteine. Da das Projekt in ei-

nem IKT-Mittelantrag im Januar 2016 mündet, kann der Endtermin nicht verschoben werden.

Die Meilensteine werden jeweils in einem Review durch den Projektausschuss münden, welcher die Er-

gebnisse in einem Projektausschussmeeting abnimmt.

Die beschriebenen Phasen bringen die hiernach genannten Ergebnisse hervor:

Ergebnisse Kurze Beschreibung Meilenstein

Projektauftrag Vereinbarung von Umfang, Qualität und Dauer der Studie Kick-Off – 09. März 2015

IST-Architektur Beschreibung der heutigen Architektur (Geschäft, Informations-

system & Technologie)

Review 1 – 31. Mai 2015 Heat-Map Identifikation und Priorisierung der wichtigsten Pain-Points basie-

rend auf der IST-Architektur.

Geschäftsprinzipien Identifikation & Evaluation der Geschäftsprinzipien der EZV

SOLL Architektur Als Grundlage wird eine unabhängige SOLL Architektur erarbei-

tet.

Review 2 – 31. Juli 2015

GAP-Analyse Evaluation der Unterschiede zwischen IST- und SOLL-Architektur

Review 3 – 30. Sept 2015

Massnahmenkata-

log

Basierend auf der GAP Analyse (IST zu SOLL) werden Massnah-

menpakete geschnürt.

Masterplan Ein Masterplan beschreibt die Umsetzung von IST zu SOLL (Zeit,

Personal, Geld)

Empfehlung Fazit der Studie inklusive Optionen zur Entscheidungsgrundlage Review 4 – 30. Nov 2015

Das Projekt wird nach Hermes 5 als eine Studie geführt. Da sich der Leistungsumfang an den gesetzten

Zielen orientiert, die Zeit und die Kosten vordefiniert sind, benutzt das Projekt agile Methoden zur Erar-

beitung und Führung. Die Projektergebnisstruktur nach Hermes ist in Abbildung 30 dargestellt.



94/107

Abbildung 29: Projektergebnisstruktur GAR-EZV

7.2 Organigramm des Projekts

Das Projekt GAR-EZV wird in der folgenden Zusammensetzung erarbeitet:

Abbildung 30: Organigramm GAR-EZV



95/107

7.3 Methodik – Anhang

7.3.1 Tailoring GAR-EVZ von SIP & TOGAF-ADM

Die folgende Abbildung erklärt die angepasste Anwendung von TOGAF-ADM und SIP im Rahmen der

Studie GAR-EZV.

Abbildung 31: Tailoring SIP & TOGAF-ADM für GAR-EZV

7.4 Strukturierte Interviews - Anhang

7.4.1 Inhaltliche Struktur der Interviews

Zur Validierung von bestehenden Informationen und Einführung der Befragten in die Thematik wurden

im ersten Teil der Interviews geschlossenen Fragen gestellt. Um das Hauptziel der Generierung von Hy-

pothesen zu erreichen wurden im zweiten und dritten Teil offene Fragen zum Ideenaustausch gestellt

und diese im vierten Teil zusammen mit dem Befragten wieder Validiert. Untenstehende Abbildung stellt

diesen Vorgang zusammengefasst dar.

Abbildung 32: Inhaltliche Struktur der Interviews GAR-EVZ



96/107

7.4.2 Auswertung der Interviews

Die Interviews stellen eine hauptsächlich qualitative Erhebung dar. Damit ist die Auswertung, Verdich-

tung und Interpretation der Aussagen einer unvermeidbaren Subjektivität ausgesetzt. Das Ziel der Befra-

gung war jedoch nicht eine absolut Vergleichbare Bewertung von vorgegebenen Aussagen zu erhalten,

sondern die qualitative Generierung von Hypothesen zur zukünftigen SOLL-Architektur der EZV. Um die

qualitativen Aussagen möglichst objektiv zu konsolidieren, wurden bereits während der Durchführung

der Interviews die Aussagen auf vorbereitete Treiber und Hypothesen gelegt. Diese inhaltliche Validie-

rung wurde danach widerholt um die Erhobenen Treiber und Hypothesen zu prüfen. Folgende Abbildung

stellt diesen Prozess dar.

Abbildung 33: Traceability von MA Aussagen (Anforderungen) zur Konsolidierung von Prinzipien

7.4.3 Interviewplanung

Die Planung der Interviews war massgeblich beeinflusst von der Auswahl der Befragten. Das Ziel der

Auswahl war die möglichst umfassende Miteinbeziehung aller organisatorischen Bereiche, Zollkreise,

Sprachregionen sowie funktionalen Themenschwerpunkten der EZV. In nachfolgender Abbildung ist die

Auswahl über die Bereiche und Funktionen dargestellt.



97/107

Abbildung 34: Auswahl der Befragten – Abdeckung EZV

Die komplette Planungsübersicht wird hier nicht angezeigt, ist auf Verlangen jederzeit einsehbar.



98/107

7.5 Geschäftsfunktionen – Anhang



99/107

7.6 Beschreibung IT-Funktionen

IT Funktion Kurzbeschreibung Fracht VSP

Abgaben / Rückerstat-tungen / Gebühren festsetzen

Vollautomatischer Systemprozess zur Berechnung anfallender Abgaben/Rücker-stattungen/Gebühren

Abgaben erheben Die berechneten/festgesetzten definitiven Beträge einfordern durch Zuweisung an Kunden, Kundenkonto oder veranlassen einer Rechnung.

Administrativmassnah-men behandeln

Administrativmassnahmen eröffnen, rapportieren, Entscheid ausstellen sowie Datenübermittlung an das Abwicklungssystem, BI-System, Geschäftsfallverwal-tung, Kundenverwaltung

Amts- und Rechtshilfe behandeln

Funktion, die dazu dient, Amts- und Rechtshilfefälle zu handhaben. Dazu gehö-ren Funktionen zur Bestätigungen, Klassifizierung und Bearbeitung von Amts- und Rechtshilfe-Anfragen

Analysen und Recher-chen bei Vorermittlun-gen

Funktion für den Zugang zu Datenbanken und anderen relevanten Informations-quellen zum Recherchieren und Analysieren von Fällen im Rahmen von Vorer-mittlungen, einschliesslich Werkzeuge für das Data-Mining (im Sinne der syste-matischen Anwendung statistischer Methoden auf grosse Datenbestände mit dem Ziel, neue Querverbindungen und Trends zu erkennen), Pattern-Matching und Korrelation.

Anbindung an Doku-mentenverwaltung

Integrationsfunktion mit der Dokumentenverwaltung, um Dokumente in die Doku-mentenverwaltung aufzunehmen, bzw. Dokumente aus der Dokumentenverwal-tung zu referenzieren.

Anbindung an elektro-nische Aktenführung

Integrationsfunktion mit der elektronischen Aktenführung, um Dokumente in die elektronische Aktenführung aufzunehmen, bzw. Dokumente aus der elektroni-schen Aktenführung zu referenzieren.

Anbindung an Fahn-dungssysteme

Funktion zur Anbindung an nationale und internationale polizeiliche Fahndungs-systeme, z.B., RIPOL, Frontex, usw.

Anbindung an Perso-nenidentifikationssys-tem

Beinhaltet Funktionen zur Anbindung an Identifikationssysteme: - Fingerabdruck-Identifikations-System (AFIS) - DNA-Datenbank (CODIS) - Zentrales Migrati-onsinformationssystem (ZEMIS) - HOOGAN DB - usw.

Aufzeichnung der Infor-mationsflüsse (Kunde, Geschäftsfall, Ereignis)

Funktion zur Aufzeichnung von Informations-Flüssen (Information-Flows) Informations-Flow: Ein Informations-Flow besteht aus einer oder mehreren Nachrichten, die zwischen den (Fach)anwendungen ausgetauscht werden, um eine fachliche Transaktion auszuführen, von der Imitierung bis zum Abschluss der Transaktion. Information-Flow-ID: Eine Information-Flow-ID ist der eindeutige technische Schlüssel eines Information-Flow. Fachliche Schlüssel (Business Keys): Für die fachliche Identifikation eines Infor-mation-Flow werden ein oder mehrere fachliche Schlüssel definiert, z.B., Kun-den-ID, Steuerperiode, usw.

Bargeldhinterlagen ver-walten

Sicherheiten, die im Zusammenhang mit dem Warentransit von Kunden als Bar-geld geleistet werden. Z.B., wenn der Transit nicht als ein Geschäftsfall im Wa-renverkehr abgewickelt wird.

Beanstandungen mel-den und verwalten

Der Informationsaustausch bezüglich Fehlern oder Rückfragen zwischen EZV und Kunde. Dies beinhaltet Detail-Funktionen wie eröffnen, beantworten, verwer-fen, historisieren, mahnen, etc.

Benutzer registrieren und verwalten (Regist-rierung)

Die Benutzerregistrierung dient zur Eintragung der Benutzer in das zentrale Be-nutzerverzeichnis, wobei zwischen internen Benutzern (Mitarbeiter EZV) und ex-ternen Benutzern unterschieden wird. Nachdem ein externer Benutzer registriert ist, kann er über ein Berechtigungsverfahren einem Kunden zugeordnet werden. Es ist zudem zu beachten, dass ein externer Benutzer unterschiedlichen Kunden



100/107


zugeordnet werden kann, welche von unterschiedlichen Fachbereichen verwen-det werden

Beschlagnahmte Ware verwalten

Registrierung und Verwaltung von beschlagnahmten Waren im Bereich grenz-überschreitender Warenverkehr, Verkehrsabgaben und Verbrauchssteuern so-wie einleiten von Massnahmen.

Beschwerden behan-deln

Unterstützt den Prozess von der Erfassung bis zum Abschluss einer Be-schwerde auf elektronischem Wege. Dabei wird die Beschwerde registriert im Verfahrensdossier eingetragen und einer Person oder Stelle zur Bearbeitung zu-gewiesen und schlussendlich abgeschlossen.

Bewilligung erteilen und verwalten

Unterstützt den Prozess von der Einreichung eines Bewilligungsantrags bis zur Ablehnung oder Annahme des Antrags.

Bewilligung prüfen und abschreiben

Im Rahmen der Annahme einer Meldung / eines Antrags wird die Bewilligung ge-prüft und ggf. abgeschrieben.

Büroanwendungen Die Zusammenstellung gebräuchlicher Software für Arbeiten im Büro, wie etwa das Schreiben von Briefen, die Tabellenkalkulation sowie das Erstellen von Prä-sentationen. Beinhaltet auch die Ablagestrukturen.

Business Process Ma-nagement

Funktion zur Abbildung und Automatisierung von Geschäftsprozessen. Zum Ge-schäftsprozessmanagement gehören die Erhebung, Gestaltung, Dokumentation und Umsetzung von Prozessen.

Complex Event Proces-sing (CEP)

Funktion zur Erkennung, Analyse, Gruppierung und Verarbeitung voneinander abhängiger Events. Die CEP Funktion umfasst Methoden, Techniken und Werk-zeuge, um Ereignisse kontinuierlich und zeitnah zu verarbeiten. CEP leitet aus Ereignissen höheres, wertvolles Wissen in Form von sog. komplexen Ereignis-sen ab, d. h. Situationen, die sich nur als Kombination mehrerer Ereignisse er-kennen lassen.

Customer Self Services Services der EZV, die von Kunden über Internet in Selbstbedienung, orts- und zeitunabhängig genutzt werden können.

Daten austauschen

Der Service Daten austauschen dient als zentraler Eingangspunkt zur EZV für Maschine-zu-Maschine-Kommunikation (M2M). Alle Kunden und Partner (EU, andere Ämter, etc.) welche mit der EZV elektronisch Daten austauschen, wer-den über den Service Daten austauschen integriert.

Daten für Auswertun-gen integrieren

Automatische Extraktion der Daten aus den operativen Quellen. Transformation, Bereinigung, Abgleich und Laden in das Data Warehouse. Historisierung und Versionierung der Daten.

Daten mit Sicherheits-organen austauschen

Funktion im Bereich grenzüberschreitender Personenverkehr zum gesicherten Austausch von Daten zwischen den EZV Fachapplikationen und den Fachappli-kationen von anderen Sicherheitsbehörden wie Polizei und Armee über das In-ternet, sowie über die einschlägigen speziellen Netze und Protokolle.

Daten transformieren und routen

Zwischen Quellsystem und Zielsystem werden die Protokoll und Format-Unter-schiede durch Transformation von Daten überbrückt. Eine Meldung wird kontext- oder inhaltsabhängig (nicht Geschäftsinformation!) zwischen Quelle und Ziel ge-routet. Auch eine Bündelung von Meldungen zählt hierzu.

Daten transportieren Umsysteme werden über Adapter an ESB angeschlossen. Die Kommunikation (synchron oder asynchron) erfolgt über ein Messaging System. Schnelle und zu-verlässige Datenübertragung (reliable messaging) wird unterstützt.

Daten ver-/entschlüs-seln

Nachrichten ver-, bzw. entschlüsseln sowie Schlüssel verwalten, ausgeben und entziehen, typischerweise mit PKI (public key infrastructure).

Datenauswertungen er-stellen

Aufbereitung eines Auszugs von spezifischen Daten in einer lesbaren und ag-gregierten Form (z.B. für Statistiken, Beauftragung Betriebskontrollen etc.) ba-sierend sowohl auf Standard Auswertungen wie auch auf individuellen Auswer-tungen. Erlaubt dynamische Auswertungen mit Drill-down, slicing/dicing etc. (OLAP)



101/107


Datenspeicher verwal-ten

Software zur Ablage, Manipulation, Abfrage und Löschung von Daten in den Da-tenbanken

Datenverkehr überwa-chen

Technisches Monitoring des Messaging Systems und der Schnittstellen. Fachli-ches Monitoring der Informationsflüsse, d.h. den Flow der Daten von der Quelle zum Ziel über fachliche Schlüssel darstellen, z.B., Geschäftsfall ID.

Datenverwaltung und Aufbereitung für Web-seiten

Erstellung, Bearbeitung und Organisation von Inhalten (Content) zumeist in Webseiten, aber auch in anderen Medienformen.

Debitorenbuchhaltung führen

Debitorenbuchhaltung befasst sich mit der Erfassung und Verwaltung der offe-nen Forderungen aus Lieferungen und Leistungen

Dokumente digitalisie-ren (Scanning)

Unter Digitalisierung versteht man allgemein die Aufbereitung von Informationen zur Verarbeitung oder Speicherung in einem digitaltechnischen System. Im en-geren Sinne geht es um das Scannen von Dokumenten oder das Erzeugen von QR-Codes.

Dokumente verwalten Speicherung, Historisierung, Versionierung von Dokumenten in festgelegten For-maten inklusive der Metadaten, sowie der Abruf der Dokumente anhand von Suchkriterien.

Echtzeit Informations-verfügbarkeit

Funktion zum Bereitstellen, Publizieren und Konsumieren von Daten in Echtzeit. D.h., die Daten einer Quellapplikation werden nach dem Push-Prinzip und in Form von leichtgewichtigen Meldungen, die nur wichtige fachliche Schlüssel und Veränderungen beinhalten, beliebigen anderen Fachapplikationen zur Verfügung gestellt.

Edelmetallware Bewilli-gungen und Verant-wortlichkeitsmarken verwalten

Funktion zur Verwaltung von Bewilligungen und Verantwortlichkeitsmarken im Bereich Edelmetallwaren.

Edelmetallwarenana-lyse steuern und aus-führen

Funktion zur Steuerung und Durchführung von Feingehaltsanalysen von Edel-metallen, sowie Prüfung von Edelmetallüberzügen.

Edelmetallwarenpun-zierung steuern und ausführen

Funktion zur Steuerung und Ausführung der amtlichen Stempelung für alle ge-setzlichen Feingehalte und Edelmetalle.

Ein- und Auszahlung Zuflüsse und Abgänge von Zahlungsmitteln verwalten. Dazu zählen im Wesentli-chen Bargeld und Bankguthaben, aber auch z.B. Schecks.

Einsatz Rapportierung Rapport Funktion über den Einsatz von Personal und Material / Fahrzeugen.

Einsatzmittel, Einsatze-reignisse und Einsätze verwalten

Beinhaltet folgende Funktionen:

Elektronische Einsatzanmeldung

Führung einer Übersicht der Einsatzmittel und deren Verfügbarkeit nach deren Status

Übersicht über die laufenden und anstehenden (zu disponierenden) Einsätze

Dokumentation aller Ereignisse im Zusammenhang mit Einsätzen

Recherchemöglichkeit in den Protokollen abgeschlossener Einsätze

Visualisierung von Stadtplänen sowie Lagedarstellung in einem Geoinformati-onssystem

Unterstützung der Alarmierung

Status Meldungen senden, empfangen, verarbeiten und historisieren

Einsatzplanung für Per-sonal und Material

Einsatz von Personal und Material / Fahrzeuge (GWK, MOBE, Fahndung, Be-triebsprüfung) planen und verwalten. Status Meldungen senden, empfangen, verarbeiten und historisieren.

Elektronisch erfassen (WebGUI)

Grafische Benutzeroberfläche (GUI), über die ein Benutzer mit Hilfe eines Webbrowsers mit dem System interagieren kann.



102/107


Elektronische Akten-führung

Systematische Kontrolle und Durchführung der Erstellung, Entgegennahme, Auf-bewahrung, Nutzung und Aussonderung von elektronischen Dokumenten, ein-schliesslich der Vorgänge zur Erfassung und Aufbewahrung von Nachweisen und Informationen über Geschäftsabläufe in Form von Akten.

Elektronische Datenla-gerung

Revisionssicheren Aufbewahrung, die der Indexierung und der Suche nach be-liebigen Dokumenten und Daten in einer Ablage dient.

Endgeräte unabhän-gige Oberflächen (Responsive Web De-sign)

Erstellung von Websites, so dass diese auf Eigenschaften des jeweils benutzten Endgeräts reagieren können. Der grafische Aufbau einer "responsiven" Website (Darstellung einzelner Elemente, Eingabemethoden) erfolgt anhand der Anforde-rungen des jeweiligen Gerätes, mit dem die Site betrachtet wird.

Entlastungen auf Abga-ben leisten

Kundenauftrag veranlassen durch Angabe von Kundenstammdaten, Gutschriften mit oder ohne Bezug.

Ereignis verwalten Funktionen zur Erfassung, Mutation (inklusive des Zeitstempels), Abruf und Be-reitstellung von Ereignisdaten im grenzüberschreitenden Personenverkehr.

Fahndung oder Über-wachung initiieren

Auslösen einer Vorermittlung, Überwachung oder Fahndung. Dazu werden die zugehörigen hochsensiblen Daten erfasst und den Sicherheitsbedürfnissen ent-sprechend abgelegt

Fakturierung inkl. Ver-sand

Rechnungsstellung und Lieferung an den Kunden oder Partner, inkl. Buchung des Geschäftsvorfalls auf den entsprechenden Konten.

File Sharing Funktion zum Bereitstellen von Files über Systemgrenzen hinweg. Der Filezugriff erfolgt rollenbasiert.

Fliegende Einsatzsys-teme, Drohnen

Einsatzpläne und Routen für fliegende Überwachungssysteme planen, erfassen und an die ausführenden Stellen übermitteln.

Formelle Bearbeitung Die formelle Bearbeitung (formelle Kontrolle) umfasst die fachliche Prüfung einer Aufgabe, das Treffen und Dokumentieren eines Entscheides darüber, was mit ei-ner Aufgabe geschieht.

Frist berechnen Fristen werden abhängig vom Verfahren, Prozess oder Status berechnet, ge-setzt und kommuniziert. Fristen können manuell oder automatisch angepasst werden.

Fristeinhaltung über-prüfen

Frist überprüfen bei eingehender Meldung oder bei periodischer Fristenkontrolle. Bei Ablauf der Frist werden Verfahrensspezifische Folgeaktivitäten ausgelöst.

Fristen definieren Funktion zum Definieren von Fristen im Bereich grenzüberschreitender Waren-verkehr, Verkehrsabgaben und Verbrauchssteuern.

Geo-Informationsaufbe-reitung

Erfassung, Bearbeitung, Organisation, Analyse und Präsentation räumlicher Da-ten.

Geschäftsfall verwalten Funktionen zur Erfassung, Mutation (inklusive des Zeitstempels), Abruf und Be-reitstellung von Geschäftsfalldaten im grenzüberschreitenden Warenverkehr, Verbrauchssteuern und Verkehrsabgaben.

Geschäftsregeln ver-walten und applizieren

Geschäftsregeln - und die operativen Entscheidungen, die mit diesen Regeln zu-sammenhängen - definieren, einsetzen, überwachen und pflegen. Fachexperten können Regeln, die das Systemverhalten steuern, definieren und pflegen, was die Zeit und den Aufwand für Produktionssystem-Updates verringert und somit die Fähigkeit der Organisation, schneller auf Veränderungen zu reagieren, er-höht.

Hauptbuch führen Im Hauptbuch sind alle Buchführungs-Konten eines Unternehmens aufgeführt (Bestandskonten und Erfolgskonten). Diese sind systematisch in einem Konten-plan gegliedert.

IKS Prüfung Freigabe Die Prüfung ist die ersten Stufe des Verfahrens, in der die Anträge/Meldungen durch die Benutzerrolle "IKS Prüfer" geprüft werden. Die Freigabe ist die zweite Stufe des Verfahrens, die Benutzerrolle *Freigeber" durchgeführt wird.



103/107


Information abfragen (Kunde, Geschäftsfall, Ereignis)

Funktion zum Abruf von Informationen aus der Geschäftsfall-, Ereignis- oder Kundenverwaltung. Der Informationsumfang ist abhängig von der Benutzerrolle.

Information übermitteln (Kunde, Geschäftsfall, Ereignis)

Funktion zur Publikation von Veränderungen im Geschäftsfall-, Ereignis- oder Kundendossier in Form von Ereignissen an Applikationen und Akteure.

Offene Forderungen einziehen (Inkasso)

Die Funktion zur Übermittlung der Forderungen gegenüber Dritten, die trotz Mahnung offen bleiben, an die Zentralen Inkassostelle (EFV) zum Inkasso.

Issue Tracking / Trou-ble Ticketing

Funktion, die dazu dient, Kundenanfragen (Tickets bzw. Fälle) zu handhaben. Dazu gehören Funktionen zur Bestätigung, Klassifizierung und Bearbeitung von Kundenanfragen. Tickets können automatisch oder manuell Rollen oder Perso-nen zugewiesen werden.

Journal führen

Diese Funktion umfasst das Führen eines elektronischen Einsatzjournals. Dies beinhaltet:

Erfassung von Meldungen

Protokollierung von Aktionen

Sprachaufzeichnung in der Einsatzzentrale

Statushandling und Historisierung

Journaldaten automa-tisch übernehmen

Automatische Übernahme der Journaldaten in andere Anwendungen (z.B. Kon-trollsystem, GEVER etc.)

Kalkulation in Abhän-gigkeit von verschiede-nen Parametern

Funktion zur Berechnung von Abgaben in den Bereichen grenzüberschreitender Warenverkehr, Verkehrsabgaben und Verbrauchssteuern

Kassenabschluss und Ablieferung

Funktion für die Schlussabrechnung und Bargeldübergabe einer Kasse, die nor-malerweise am Ende eines Tages vorgenommen wird.

Kassenzahlung leisten Zahlungsstellenfunktion, die der Abwicklung von Zahlungsvorgängen mit Bar-geld, Schecks, Geldkarten und Kreditkarten dient.

Kommunikation mit Ar-mee und Polizei (ad hoc)

Funktionen, im Bereich Personenverkehr die benötigte werden, mit Armee und Polizei über spezielle Netze und Protokolle ad hoc zu kommunizieren, sowie die benötigten Kommunikationsgeräte zu programmieren.

Kommunikationskanäle bereitstellen (ad hoc)

Diese Funktion umfasst die ad hoc Kommunikation über Telefonie, UCC, Funk.

Kontingente erteilen und entziehen

Diese Funktion dient der Verwaltung (Prüfen, Erteilen, Entziehen) von Kontin-genten. Zollkontingente sind Verpflichtungen z.B. im Agrarbereich, einer be-stimmten Menge eines Erzeugnisses unter bestimmten Voraussetzungen den Marktzugang zu einem tieferen Zollansatz zu gewähren. Es wird unterschieden zwischen Individualkontingenten des BLW und Sammelkontingenten der EZV.

Kontingente prüfen und abschreiben

Die Funktion dient dazu, Kontingente zu prüfen und abzuschreiben im Rahmen von Zollanmeldungen.

Kontrollbefund doku-mentieren

Kontrollresultate nach Standardvorgaben und abhängig von der Kontrollart erfas-sen.

Kontrolle von Reisedo-kumenten

Funktion zur Überprüfung von Reisedokumenten. Dies beinhaltet den automati-schen Vergleich zwischen den biometrischen erfassten Daten und den Daten aus den Reisedokumenten wie auch eine Plausibilitätsprüfung, Ergebnisdarstel-lung und Alarming.

Kreditorenbuchhaltung führen

Die Kreditorenbuchhaltung ist ein Nebenzweig der Finanzbuchhaltung, der spe-ziell für die Buchführung der Kontokorrentbeziehungen zwischen dem eigenen Unternehmen und den Kreditoren zuständig ist. Die Hauptaufgabe der Kredito-renbuchhaltung ist die Bearbeitung der kreditorischen Eingangsrechnungen.

Kunden verwalten Erfassung, Mutation (inklusive des Zeitstempels), Abruf und Bereitstellung von Kundendaten durch die EZV, bzw. den Kunden selber. Zu Kundendaten gehören



104/107


Kunden ID, Rolle, Kontakt, Benutzer, Benutzerrollen, Benutzerkontakte, persönli-che Benutzerdaten, usw.

Labor Notebooks füh-ren

Experimente, Forschung und Prozeduren dokumentieren, die im Labor durchge-führt werden.

Mahnwesen für Kredi-toren und Debitoren

Funktion zum Definieren des Verfahrens, wie Debitoren oder Kreditoren ge-mahnt werden können. Zu einem Mahnverfahren werden u.a. die Anzahl der Mahnstufen, der Mahnrhythmus und die Mahntexte festgelegt. Das Mahnwesen wird mit dem Mahnprogramm automatisch abgewickelt: Das Programm ermittelt die zu mahnenden Konten und Posten, die Mahnstufe des Kontos und anhand der Mahnstufe den Mahnbrief. Mit dem Druckprogramm werden die Mahnbriefe gedruckt. Dabei werden die ermittelten Mahndaten in Posten und Konten gespei-chert.

Materialanalyse durch-führen

Funktion zur Datenverarbeitung im analytischen Labor. Die Funktion umfasst die Registrierung des Probeneingangs, die Kontrolle und Begleitung des gesamten Messprozesses bis zur wissenschaftlichen Auswertung der Untersuchung, inkl. der Steuerung der personellen und technischen Ressourcen.

Materielle Kontrolle durchführen

Funktion zum Durchführen von materiellen Kontrollen im Bereich grenzüber-schreitender Warenverkehr, Verkehrsabgaben und Verbrauchssteuern.

Materielle Kontrolle er-fassen

Funktionen zum Dokumentieren von materiellen Kontrollen im Bereich grenz-überschreitender Warenverkehr, Verkehrsabgaben und Verbrauchssteuern.

Materielle Kontrolle pla-nen und vorbereiten

Funktionen zum Planen und Vorbereiten materieller Kontrollen im Bereich grenz-überschreitender Warenverkehr, Verkehrsabgaben und Verbrauchssteuern.

Meldung / Formular verarbeiten

Diese Funktion umfasst folgende Aufgaben:

Meldungstyp erkennen

Meldung validieren

ggf., weitere Informationen einholen

entsprechendes Verfahren initiieren

Mobile Biometrie Da-tenerfassung

Mobile Biometriedatenerfassung inkl. Echtzeit Antwort zur automatisierte Erken-nung von Individuen, basierend auf ihren Verhaltens- und biologischen Charak-teristika (DNA, Fingerabdruck, Gesichtsgeometrie, Handgeometrie, Iris, Retina, Stimme, Unterschrift, usw.)

Mobiler Zugriff auf Ap-plikationen

Funktion zum ortsunabhängigen Zugriff auf Fachapplikationen. Beinhaltet die Fähigkeit, Geschäftsfälle über mobile Geräte abzuwickeln, inklusive Erfassen, Abfragen, Rückmelden. D.h., ein Rückgriff auf Desktop Arbeitsplätze ist nicht er-forderlich.

Nutzer authentisieren und autorisieren

Benutzer werden authentisiert nach den erforderlichen Sicherheitsanforderungen (z.B. 2-Faktor-Authentisierung). Dies beinhaltet:

Benutzer und Rollen verwalten

Rollen auf Zugriffsberechtigungen abbilden

Authentisieren

Autorisieren

Single Sign-On ermöglichen

Online Zahlung leisten Funktionen zur Zahlung via Internet mit verschiedenen Zahlungsarten: - per Bankeinzug - per Kreditkarte - per drittes Online-Bezahlsystem - per Rechnung

Ortung

Verfahren zur Positionsbestimmung entfernter Objekte. Grundlage ist in der Re-gel eine vom Beobachter vorgenommene Distanzmessung mittels Signalen, die vom zu ortenden Objekt an den Sender zurück gelangen. Verwendet werden u.a., Laser, Tonsignale, Radar, GSM. GSM-Ortung bezeichnet die Ortsbestim-mung eines eingeschalteten und in ein Funknetz eingebuchten, auf der Basis von Global System for Mobile Communications (GSM) betriebenen Endgerätes durch das Mobilfunknetz.

Output Management Output Management hat die Versorgung von Mitarbeitern und Externen (Kun-den, Interessenten etc.) mit notwendigen Dokumenten zum Ziel. Zudem sollten



105/107


die Dokumente leicht lesbar, druckbar oder speicherbar sein. Dokumente kön-nen mit verschiedenen Technologien erzeugt und kommuniziert werden (Druck, E-Mail).

Partner Access Policy Enforcement

Eine Komponente, die den sicheren Zugriff aus Internet auf Applikationen im in-ternen Netz ermöglicht. Dazu gehört:

Partner Authentisierung und Autorisierung

Zugriffsprotokollüberwachung

Transport-Verschlüsselung

Verhinderung von Angriffen

Pendenzen-/Statusliste führen

Diese Funktion wird auch als Arbeitsvorrat bezeichnet. Der Arbeitsvorrat ist eine Sammlung von Aufgaben einer Organisationseinheit. Die Aufgaben im Arbeits-vorrat werden in Kategorien gegliedert angezeigt. Alle Benutzer einer Organisati-onseinheit haben Zugriff auf denselben Arbeitsvorrat. Die Benutzer sehen alle Aufgaben und ob und bei welchem Benutzer die Aufgaben in Bearbeitung sind.

Plausibilisierung durchführen

Systemprozess, der die Plausibilisierung nach definierten Geschäftsregeln auto-matisch durchführt. Neben der Prüfung auf Vollständigkeit und Schemakonfor-mität von einkommenden Meldungen werden auch die fachlichen Inhalte abhän-gig vom Verfahren geprüft.

Portal-Integration und -Lenkung

Funktion zur Lenkung der Benutzer zu entsprechenden Fachanwendungen und zum Datenaustausch zwischen den Fachanwendungen auf Portalebene.

Präsentation der Daten Funktion zur zielgruppenspezifischen Darstellung von Informationen und Daten in strukturierter Form und unter Verwendung visueller Hilfsmittel (Charts, Graphi-ken, ...).

Prozessablauf steuern Beinhaltet die Funktionen zur grafischen Modellierung der Arbeitsabläufe, zur Ausführung und Steuerung der modellierten Arbeitsabläufe.

Referenzdaten bereit-stellen

Als Referenzdaten oder Stammdaten (englisch Master Data) werden Daten be-zeichnet, die Grundinformationen über Geschäftsobjekte enthalten, die zur lau-fenden Verarbeitung erforderlich sind. Die Funktion dient der Bereitstellung die-ser Referenzdaten.

Referenzdaten verwal-ten

Funktionen zum Erstellen, zum Pflegen, zur Vereinheitlichung und Verwaltung von Stammdaten.

Risikoanalyse und Re-porting

Funktion zur Bewertung einzelner Risiken im Hinblick auf deren Einfluss, Wich-tigkeit und Wahrscheinlichkeit. Es werden numerische oder qualitative Werte für das Risiko ermittelt, die helfen sollen ein Risiko einzuschätzen. Darüber hinaus, werden Ergebnisse der Risikoanalyse als Reports bereitgestellt.

Rückerstattungen gut-schreiben

Berechnete Rückerstattung wird je nach Anforderung einem Kunden, einem Konto, einer Bürgschaft oder einer anderen finanzbuchhalterischen Verrech-nungseinheit zugewiesen. Dies kann zu einer Kontoentlastung oder zu einer Auszahlung führen.

Sachanlagen verwalten (führen und bewirt-schaften)

Funktion zur Bewirtschaftung von Material und Fahrzeuge (inkl. Beschaffen, ver-kaufen, investieren, etc.) sowie zum Führen des Inventar (Material, Fahrzeuge, IKT etc.). Das Inventar wird auf der Benutzerebene geführt.

Selektion ausführen Die plausibilisierten und angenommenen Geschäftsfälle werden aufgrund defi-nierter Geschäftsregeln selektioniert. Die Selektionskriterien können u.a. auf-grund von Zeitpunkt, Ort, Grenzwert, Risiko oder Zufallsprinzip gesetzt werden

Sicherheiten verwalten

Sicherheiten zur Absicherung des Zollgeschäfts verwalten, dies beinhaltet fol-gende Funktionen:

Ermitteln und Festlegen von Sicherheiten

Anpassung der Höhe der Sicherheiten

Manuelle / automatische Überprüfung von Sicherheiten

Vergleich mit Debitorenbeträgen

Abfrage der Höhe der Sicherheiten und Debitorenbeträge

Aufteilung / Zusammenführung der Sicherheiten



106/107


Meldung auslösen bei Unterdeckung

Signaturen verwalten Elektronische Signaturen und Zertifikate für die Maschine-2-Maschine Kommuni-kation herausgeben, wiederrufen und überprüfen. Nutzung der PKI Infrastruktur

Social Collaboration Funktion zur Nutzung von Fachapplikations-Chats, -Diskussionsforen, -Umfra-gen, usw., zum Zweck einer gemeinsamen und vernetzten Interaktion zwischen den Kunden und der EZV.

Stammdaten beziehen und interpretieren

Funktion zum Beziehen und Mappen der benötigten Stammdaten in den Kontext der nutzenden Fachapplikation.

Stationäre Biometrie Datenerfassung

Stationäre Biometriedatenerfassung inkl. Echtzeit Antwort zur automatisierte Er-kennung von Individuen, basierend auf ihren Verhaltens- und biologischen Cha-rakteristika (DNA, Fingerabdruck, Gesichtsgeometrie, Handgeometrie, Iris, Re-tina, Stimme, Unterschrift, usw.)

Strafverfahren behan-deln

Beinhaltet die Eröffnung, Durchführung, Rapportierung von Strafverfahren sowie die Ausstellung von Strafbefehlen oder Anzeigen. Daten der Vorermittlung wer-den übernommen.

Suchanfrage verarbei-ten

Es handelt sich um eine Suchfunktion auf mehreren Ebenen:

Suchformular

Suchen im Portal-Kontext (public und restricted)

Suchen im Geschäftsfalldossier, Kundendossier oder Ereignisdossier-Kontext

Funktionseinschränkung gemäss Benutzerrolle

Suchanfrage an Fachapplikationen weitergeben und Ergebnis aufbereiten

Export von Suchergebnissen

Technische ID's verwal-ten

Pro Geschäftsfall oder Ereignis wird eine globale ID verwendet und abgelegt. Fachanwendungsspezifische ID’s. sowie ID’s von Partnersystemen werden zent-ralen gehalten und mit der globalen ID assoziiert. Auflösung der globalen ID in die einzelnen lokalen ID’s pro Geschäftsfall oder Ereignis wird unterstützt

Temporale Datenhal-tung (Historisierung)

Die Funktion zum Festhalten der zeitlichen Entwicklung der Daten bei deren Speicherung.

Transportmittel verwal-ten

Funktionen zur Erfassung, Mutation, Abruf und Bereitstellung von Transportmit-teldaten im grenzüberschreitenden Warenverkehr, Verkehrsabgaben und grenz-überschreitendem Personenverkehr.

Veranlagungsverfü-gung ausstellen

Automatische erstellter Nachweises in Form einer elektronischen Veranlagungs-verfügung wird zum Abruf elektronisch bereitgestellt oder ggf. an das Output-Ma-nagement übermittelt.

Vergleich von unab-hänigen Prozessen

Auf der Prozessebene unabhängige Prozesse werden auf der Datenebene ver-glichen, überprüft und im Negativfall wird ein Notifikation ausgegeben

Verwendungsverpflich-tung erteilen und ver-walten

Bestimmte Waren können gestützt auf ihre Verwendung zu einem reduzierten Zollansatz veranlagt werden. Für die Inanspruchnahme des reduzierten Ansat-zes wird eine Verwendungsverpflichtung benötigt. Diese muss in der Einfuhrver-anlagung entsprechend deklariert werden.

Verwendungsverpflich-tung prüfen

Prüfung bei der Zollanmeldung, ob der reduzierte Ansatz zu Recht beantragt wird und der Zollbeteiligte über die erforderliche Verwendungsverpflichtung ver-fügt.

Verzeichnisdienst (Identity Store)

Ein Verzeichnisdienst (englisch directory service) stellt in einem Netzwerk eine zentrale Sammlung an Daten bestimmter Art zur Verfügung. Verzeichnisdienste werden in der Regel dazu verwendet, Benutzerdaten zentral zu sammeln und Applikationen zur Verfügung zu stellen.

Vorhandene Daten übernehmen

Bereits vorhandene Daten (z.B. aus früherer Übermittlung oder Zwischenspei-cherung) werden ermitteln und können automatisch übernommen werden. Ein-gabeformulare werden damit vorausgefüllt. Die Übernahme der Daten wird auch zwischen unterschiedlichen Systemen unterstützt.



107/107


Warenbuch führen (Kunde, Produkt, Standort)

Unverzollte Waren werden nach allgemein gültigen Buchhaltungsgrundsätze ba-sierend auf Konten geführt. Die Warenbestände und Bewegungen werden auf-grund von Anmeldungen im Warenbuch geführt. Der Lagerbestand wird pro Wa-renart geführt. Sowohl die Bewegungen wie auch der Saldo sind jederzeit abruf-bar.

Warenfluss verwalten Warenbewegungen vornehmen

Lagerbestand pro Warenart nachführen und abrufen

Berechnung der aktuellen Warenbestände auf Anforderung

Warenvergleich durch-führen

Automatische Gegenüberstellung und Vergleich von Anträgen/Meldungen, Ein-/Ausgangsmeldung, Zollanmeldungen, usw.

Berücksichtigung von Toleranzgrenzen und Unterschieden in der Periodizität der Meldungen

Unstimmigkeiten automatisch melden und anzeigen

Vergleich zwischen dem gemeldeten effektiven Warenbestand und dem buch-mässigen Bestand anstellen im Rahmen der Gewinn/Verlust-Kontrolle unter Berücksichtigung von definierten Toleranzwerten

Wissensmanagement Funktionen zur Identifikation, Sammlung, Anreicherung, Bewahrung, Nutzung und Verteilung von Wissen

Zellüberwachung Ansteuerung und Bildübertragung von Überwachungskameras der Inhaftierungs-zellen,

Zentralen Zugriff bereit-stellen

Zugriff zum zentralen Portal

Single-Sign-On

GUI gemäss Vorgaben CD Bund

Inhalte entsprechend Benutzerrollen aufbereiten

Definierte Eingabemasken für interne und externe Benutzer

GUI kann personalisiert werden

Dokumente per Eingabemaske übermitteln

Ausgabemasken generieren

Kunden bewerten

Bewertung der Kunden zwecks Rating, Risikobeurteilung

Aussagen über Notwendigkeit / Dringlichkeit von Kontrollen

Automatische Erstellung des Prüfplans

Bereitstellung Kundenprofil (objektive und subjektive Indikatoren, Dashboard) und Ratingklasse

Auskunft für Kunden bereitstellen

Zertifikate erteilen und verwalten

Erteilen des Status AEO (Authorised Economic Operator) nach Artikel 42a des Zollgesetzes vom 15. März 2005 (ZG, SR 631.0) und Artikel 112a der Zollverord-nung vom 1. November 2006 (ZV, SR 631.01). Durch den AEO-Status erhält die zertifizierte Firma Vorteile / Erleichterungen wie vorrangige Behandlung bei der Überprüfung / weniger Sicherheitskontrollen von Waren / Summarische Anmel-dung der Waren / internationale Anerkennungen

Zertifikate prüfen Im Zusammenhang mit den obgenannten Bereichen prüfen, ob der Zollbeteiligte über das erforderliche AEO-Zertifikat verfügt.

Zoll-Pad

Massgeschneiderte standardisierte rollenbasierend einsetzbare mobile HW-Ap-pliance (inklusive Scanner/Kamera/Einlesegerät/Kommunkation) zum Einsatz im Waren- bzw. Personenverkehr mit Funktionen für Biometrie, Personenidentifika-tion, Warenkontrolle und Zugriff auf die Kern-Fachanwendungen.

Zollregister (Verzeich-nisse) publizieren

Ein Verzeichnis im Internet oder Intranet publizieren, in welchem bestimmte In-formationen zu Kunden, Tarifen für eine definierte Zielgruppe einsehbar sind.

Zollregister (Verzeich-nisse) Suchfunktion

Suchfunktion für Verzeichnisse im Zollregister bereitstellen. Es wird unterschie-den zwischen öffentlichem, halb-öffentlichem und privatem Verzeichnis

Tabelle 30: Beschreibung IT-Funktionen

Documents

GAR-EZV Dokument B SOLL-Architektur · 1/107 GAR-EZV Dokument B SOLL-Architektur Klassifizierung * Nicht klassifiziert Status ** Abgenommen Projektname „Geschäftsprinzipien, IT-Architektur