Jingga/Organization-Guide
1
0
Fork 0
mirror of https://github.com/Karaka-Management/Organization-Guide.git synced 2026-01-16 23:08:41 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

Merge branch 'master' of https://github.com/Karaka-Management/Organization-Guide

Browse Source
This commit is contained in:
Dennis Eichhorn 2022-06-15 20:27:30 +02:00
commit effcb5d274
31 changed files with 133 additions and 143 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
.obsidian/app.json vendored
View File

@ -1,4 +0,0 @@
{
"legacyEditor": false,
"livePreview": true
}

1
.obsidian/appearance.json vendored
View File

@ -1 +0,0 @@
{}

15
.obsidian/core-plugins.json vendored
View File

@ -1,15 +0,0 @@
[
"file-explorer",
"global-search",
"switcher",
"graph",
"backlink",
"page-preview",
"note-composer",
"command-palette",
"editor-status",
"markdown-importer",
"word-count",
"open-with-default-app",
"file-recovery"
]

1
.obsidian/hotkeys.json vendored
View File

@ -1 +0,0 @@
{}

97
.obsidian/workspace vendored
View File

@ -1,97 +0,0 @@
{
"main": {
"id": "36839c96192b8840",
"type": "split",
"children": [
{
"id": "8f73e522b82de672",
"type": "leaf",
"state": {
"type": "markdown",
"state": {
"file": "Project/Pilot1/Costs.md",
"mode": "source",
"source": false
}
}
}
],
"direction": "vertical"
},
"left": {
"id": "db37bce5d93c4de8",
"type": "split",
"children": [
{
"id": "0d59aa8557971c88",
"type": "tabs",
"children": [
{
"id": "6911b67edda611ab",
"type": "leaf",
"state": {
"type": "file-explorer",
"state": {}
}
},
{
"id": "a3438aede50c771f",
"type": "leaf",
"state": {
"type": "search",
"state": {
"query": "",
"matchingCase": false,
"explainSearch": false,
"collapseAll": false,
"extraContext": false,
"sortOrder": "alphabetical"
}
}
}
]
}
],
"direction": "horizontal",
"width": 300
},
"right": {
"id": "67cc9914d87bad8c",
"type": "split",
"children": [
{
"id": "42a368a1f71131b3",
"type": "tabs",
"children": [
{
"id": "ff4b58e0df015702",
"type": "leaf",
"state": {
"type": "backlink",
"state": {
"file": "Project/Pilot1/Costs.md",
"collapseAll": false,
"extraContext": false,
"sortOrder": "alphabetical",
"showSearch": false,
"searchQuery": "",
"backlinkCollapsed": false,
"unlinkedCollapsed": true
}
}
}
]
}
],
"direction": "horizontal",
"width": 300,
"collapsed": true
},
"active": "8f73e522b82de672",
"lastOpenFiles": [
"Project/Pilot1/Costs.md",
"Project/Pilot1/Timeline.md",
"Project/PROJECT.md",
"Project/Module Features.md"
]
}

0
Legal/GDPR.md → App/GDPR.md
View File

0
Legal/GDPdU.md → App/GDPdU.md
View File

1
Policies & Guidelines/Accounting.md Normal file
View File

@ -0,0 +1 @@

22
Processes/Development.md → Processes/01_Development.md
View File

@ -26,13 +26,15 @@ Open tasks can be found in the project overview: [PROJECT.md](https://github.com
Tasks currently in development are prefixed in the priority column with an asterisk `*` and a name tag in the task description of the developer who is working on the task.
The open tasks are reviewed once a month by a senior developer. The senior developer updates the project overview if necessary and requests feedback regarding development status of important tasks under development. During this process important tasks may also get directly assigned to developers. This review is performed on a judgmental bases of the senior basis.
The open tasks are reviewed once a month by a senior developer. The senior developer updates the project overview if necessary and requests feedback regarding development status of important tasks under development. During this process important tasks may also get directly assigned to developers. This review is performed on a judgmental bases of the senior basis.
### Code style
### Quality
Code changes must follow the [style guidelines](https://github.com/Karaka-Management/Developer-Guide/tree/develop/standards). Additionally, the automatic code style inspection tools must return no errors, failures or warnings. Developers should test their changes with inspection tools and configurations mentioned in the [inspection documentation](https://github.com/Karaka-Management/Developer-Guide/blob/develop/quality/inspections.md) in advance before submitting them for review.
#### Code style
In rare cases errors, failures or warnings during the automatic inspection are acceptable. Reasons can be changes in the programming language, special cases which cannot, are difficult or must be individually configured in the inspection settings. If this is the case for a code change and if inspection configuration changes are necessary are decided by the senior developer performing the code review.
Code changes must follow the [style guidelines](https://github.com/Karaka-Management/Developer-Guide/tree/develop/standards). Additionally, the automatic code style inspection tools must return no errors, failures or warnings. Developers should test their changes with inspection tools and configurations mentioned in the [inspection documentation](https://github.com/Karaka-Management/Developer-Guide/blob/develop/quality/inspections.md) in advance before submitting them for review.
In rare cases errors, failures or warnings during the automatic inspection are acceptable. Reasons can be changes in the programming language, special cases which cannot, are difficult or must be individually configured in the inspection settings. If this is the case for a code change and if inspection configuration changes are necessary are decided by the senior developer performing the code review.
Automated checks which are run during the review process:
@ -41,7 +43,7 @@ php ./vendor/bin/phpcs ./ --standard="Build/Config/phpcs.xml"
npx eslint ./ -c ./Build/Config/.eslintrc.json
```
### Tests
#### Tests
Code changes must follow the inspection guidelines (i.e. code coverage) mentioned in the [inspection documentation](https://github.com/Karaka-Management/Developer-Guide/blob/develop/quality/inspections.md). Developers should check if the code changes comply with the inspection guidelines before submitting them.
@ -58,11 +60,7 @@ npx jasmine-node ./
Additional inspections which are run but might be ignored during the review depending on the use case are mentioned in the [inspection documentation](https://github.com/Karaka-Management/Developer-Guide/blob/develop/quality/inspections.md) as other checks.
### Demo
Some code changes may also require changes or extensions in the demo setup scripts. The demo setup script try to simulate a real world use case by generating and modifying mostly random data. This is also a good way to setup and “manually” test the code changes in a larger picture. The demo setup script can be found in the [demoSetup](https://github.com/Karaka-Management/demoSetup) repository. The demo setup script takes a long time due to the large amount of user input simulated data which is generated. Therefore it is recommended to run this only sporadically.
### Code review
#### Code review
In addition to the automatic code review performed by the various inspection tools such as (phpcs, phpstan, phpunit, eslint and custom scripts) a senior developer must check the proposed code change before it is merged with the respective `develop` branch. Only upon the approval by the reviewer a code change requests gets merged as no other developers have permission in the software to make such code merges.
@ -70,6 +68,10 @@ In case a code change request is not approved the reviewer states the reason for
If the code reviewer only finds minor issues with the proposed code change the reviewer may make small changes to the proposed code change and inform the contributor to speed up the implementation process. Code reviewers are encouraged to do this with new contributors to avoid long iteration processes and to not discourage new developers. However, communication is key and severe issues with code change requests or if the contributor already made multiple code change requests in the past the reviewer should not implement the improvements by himself and rather decline the code change requests with his reasoning.
#### Demo
Some code changes may also require changes or extensions in the demo setup scripts. The demo setup script try to simulate a real world use case by generating and modifying mostly random data. This is also a good way to setup and “manually” test the code changes in a larger picture. The demo setup script can be found in the [demoSetup](https://github.com/Karaka-Management/demoSetup) repository. The demo setup script takes a long time due to the large amount of user input simulated data which is generated. Therefore it is recommended to run this only sporadically.
### Release flow
Code changes must be performed in a new branch. A new branch can be created with:

0
Processes/Development_Flowchart.md → Processes/01_Development_Flowchart.md
View File

0
Processes/Purchase.md → Processes/02_Purchase.md
View File

56
Processes/03_Sales.md Normal file
View File

@ -0,0 +1,56 @@
# Sales
## Acquesition
### Prospect Initiated
### Karaka Initiated
## Offer
| No. | R | Category | Risk Event | L | C | O | Mitigation Strategy | L* | C* | Changes | Comments | ES | EY |
| -------- | ---- | ---------------- | ------------------------------------------------------------ | ---- | ---- | ---- | ------------------------------------------------------------ | ---- | ---- | ------- | ------------------------------------------------------------ | ---- | ---- |
| 1 | Head of Sales / Head of Finance | Operational Risk (Sales) | Prices too low / discounts too large | 1 | 5 | Many times a day | Avoiding: Default prices and standard discounts are stored in the IT system responsible for the offer generation. Deviations require additional electronical approval in the system by the head of sales or head of finance. Without this electronic approval the offer cannot get created. | | | | | yes | yes |
| No. | Risks/Things to consider | Mitigation Strategy | R | O |
| ---- | ------------------------------------ | ---------------------- | ---- | ---- |
| C3 | Prices too low / discounts too large | Default prices and standard discounts are stored in the IT system responsible for the offer generation. Deviations require additional electronical approval in the system by the head of sales or head of finance. Without this electronic approval the offer cannot get created. | Head of Sales / Head of Finance | Weekly |
| C4 | Default prices are too low / default discounts are too large | Changes to default prices and default discounts can only be entered into the IT system by the head of sales or head of finance. | Head of Sales / Head of Finance | Annualy |
| C5 | Other aspects of the offer are invalid (i.e. wrong customer, bad credit score of customer, ...) | The offer is none-binding and only becomes binding with the order confirmation where additional checks are performed. | Automatic | Many times a day |
## Contracts
| No. | Risks/Things to consider | Mitigation Strategy | R | O |
| ---- | ------------------------ | ---------------------- | ---- | ---- |
| C6 | Old contract version is used | | | |
| C7 | Contract changes are invalid | | | |
## Order Confirmation
### Credit Check
| No. | Type | Risks/Things to consider | Mitigation Strategy | R | O |
| ---- | ---- | ------------------------ | ---------------------- | ---- | ---- |
| C1 | Preventing | Invalid customer data | Customer data gets compared with the information provided from credit rating agencies, company registration forms etc. | System | Many times a day |
| C2 | Preventing | Customer default | Only customers with a credit score of XXXX-Crefo / XXXX-Coface / XXXX-Schufa get approved during the order confirmation. | System | Many times a day |
## Delivery Note
## Invoice
## Collection
## Accounts Receivables
| No. | Risks/Things to consider | Mitigation Strategy | R | O |
| ---- | ------------------------ | ---------------------- | ---- | ---- |
| | | | | |
| | | | | |
| | | | | |
Abbreviations:
* R: Responsible
* O: Occurrence
* T: Type

0
Processes/Support.md → Processes/04_Support.md
View File

0
Processes/Payroll.md → Processes/05_Payroll.md
View File

0
Processes/Inventory.md → Processes/06_Finance.md
View File

1
Processes/06_Finance_Flowchart.md Normal file
View File

@ -0,0 +1 @@

0
Processes/Management.md → Processes/07_Management.md
View File

1
Processes/08_Quality Management Normal file
View File

@ -0,0 +1 @@

2
Processes/COSO/Risk Management/Risk Register.md
View File

@ -2,7 +2,7 @@
The risk register is a central repository to describe and track risks as well as record actions. It includes information for each risk such as risk category, likelihood, consequence, mitigation measures, risk owner and documentation of changes.
| Risk No. | R | Category | Risk Event | L | C | O | Mitigation Strategy | L* | C* | Changes | Comments | ES | EY |
| No. | R | Category | Risk Event | L | C | O | Mitigation Strategy | L* | C* | Changes | Comments | ES | EY |
| -------- | ---- | ---------------- | ------------------------------------------------------------ | ---- | ---- | ---- | ------------------------------------------------------------ | ---- | ---- | ------- | ------------------------------------------------------------ | ---- | ---- |
| 1 | DE | Operational Risk | Loss of source code | 1 | 5 | | Avoiding: Store source code in cloud (github). At least one local developer PC and project server. | | | | | yes | yes |
| 2 | DE | Operational Risk | Source code leak | 5 | 1 | | Controlling: The programming language is compiled at runtime. The value of the software lies in the updates, support and licenses. | | | | Many companies transferred the revenue model to subscriptions (e.g. Adobe, Microsoft) in order to avoid similar problems. | yes | yes |

14
Processes/HR/Colleague Evaluation.md Normal file
View File

@ -0,0 +1,14 @@
| No. | Collegue Evaluation | Very Confident | Fairly Confident | Not Very Confident | Not At All Confident | Notes |
| ---- | ----------------------------- | ---------------| ---------------- | ------------------ | -------------------- | ----- |
| 2 | My colleques a broad and deep knowledge overy my work field. | [ ] | [ ] | [ ] | [ ] | |
| 3 | My colleques also considering my job/department when doing their work. | [ ] | [ ] | [ ] | [ ] | |
| 4 | My colleques are flexible. | [ ] | [ ] | [ ] | [ ] | |
| 5 | My colleques are motivated. | [ ] | [ ] | [ ] | [ ] | |
| 6 | My colleques are good at communication. | [ ] | [ ] | [ ] | [ ] | |
| 7 | My colleques share information with me accordingly. | [ ] | [ ] | [ ] | [ ] | |
| 8 | My colleques are team players. | [ ] | [ ] | [ ] | [ ] | |
| 10 | My colleques complete assigned work effectively and on time. | [ ] | [ ] | [ ] | [ ] | |
| 12 | My colleques are resilient. | [ ] | [ ] | [ ] | [ ] | |
| 13 | My colleques show initiative. | [ ] | [ ] | [ ] | [ ] | |
| 14 | My colleques work autonomusly. | [ ] | [ ] | [ ] | [ ] | |

1
Processes/HR/Company Evaluation.md Normal file
View File

@ -0,0 +1 @@

1
Processes/HR/Employee Evaluation.md Normal file
View File

@ -0,0 +1 @@

2
Legal/Individual Contributor License Agreement.md → Processes/HR/Individual Contributor License Agreement.md
View File

@ -50,4 +50,4 @@ This agreement constitutes the entire agreement and supersedes all prior or cont
2022.01.01 - Version 1.0
2022.01.01 - Version 1.0

22
Processes/HR/Self-Evaluation.md Normal file
View File

@ -0,0 +1,22 @@
# HR Self-Evaluation Form
Name:
| No. | Self-Evaluation | Very Confident | Fairly Confident | Not Very Confident | Not At All Confident | Notes |
| ---- | ----------------------------- | ---------------| ---------------- | ------------------ | -------------------- | ----- |
| 1 | I possess sufficient resources for me to achieve my tasks. | [ ] | [ ] | [ ] | [ ] | |
| 2 | I have a broad and deep knowledge overy my work field. | [ ] | [ ] | [ ] | [ ] | |
| 3 | I am also considering other people and departments when doing my work. | [ ] | [ ] | [ ] | [ ] | |
| 4 | I am flexible. | [ ] | [ ] | [ ] | [ ] | |
| 5 | I am motivated. | [ ] | [ ] | [ ] | [ ] | |
| 6 | I am good at communication. | [ ] | [ ] | [ ] | [ ] | |
| 7 | I share information with my colleques and supvervisors accordingly. | [ ] | [ ] | [ ] | [ ] | |
| 8 | I am a team player. | [ ] | [ ] | [ ] | [ ] | |
| 9 | I have a confident presence in my field of work. | [ ] | [ ] | [ ] | [ ] | |
| 10 | I complete assigned work effectively and on time. | [ ] | [ ] | [ ] | [ ] | |
| 11 | I am fully occupied with my work. | [ ] | [ ] | [ ] | [ ] | |
| 12 | I am resilient. | [ ] | [ ] | [ ] | [ ] | |
| 13 | I show initiative. | [ ] | [ ] | [ ] | [ ] | |
| 14 | I can work autonomusly. | [ ] | [ ] | [ ] | [ ] | |
| 15 | I am good at negotiating. | [ ] | [ ] | [ ] | [ ] | |
| 16 | I am good at leading my subordinate. | [ ] | [ ] | [ ] | [ ] | |

11
Processes/Interdependency.md Normal file
View File

@ -0,0 +1,11 @@
| | Development | Purchase | Sales | Management | Payroll | Inventory | Support & Service | Quality Management |
| - | - | - | - | - | - | - | - | - |
| Development |
| Purchase |
| Sales |
| Management |
| Payroll |
| Inventory |
| Support & Service |
| Quality Management |

7
Processes/Organigram.md Normal file
View File

@ -0,0 +1,7 @@
```mermaid
graph TD;
A---B;
A---C;
B---D;
C---D;
```

13
Processes/Sales.md
View File

@ -1,13 +0,0 @@
# Sales
| No. | Process step | Risks/Things to consider | Checks/Risk mitigation | R | O |
| ---- | ------------ | ------------------------ | ---------------------- | ---- | ---- |
| | | | | | |
| | | | | | |
| | | | | | |
Abbreviations:
* R: Responsible
* O: Occurrence

1
Processes/Sales/General Terms and Conditions.md Normal file
View File

@ -0,0 +1 @@

1
Processes/Sales/Maintenance Contract.md Normal file
View File

@ -0,0 +1 @@

1
Processes/Sales/Requirement Checklist.md Normal file
View File

@ -0,0 +1 @@

1
Processes/Sales/Setup Checklist.md Normal file
View File

@ -0,0 +1 @@