Jingga/Organization-Guide
1
0
Fork 0
mirror of https://github.com/Karaka-Management/Organization-Guide.git synced 2026-01-11 12:58:42 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

update

Browse Source
This commit is contained in:
Dennis Eichhorn 2022-07-07 18:24:47 +02:00
parent 135c60d1a6
commit 54c5559505
41 changed files with 769 additions and 135 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1
Policies & Guidelines/Documentation Type Overview.md → Documentation Type Overview.md
View File

@ -24,3 +24,4 @@
* Forms
* Forms to be used for certain organization activities

51
Policies & Guidelines/Sales/Pricing Policy.md
View File

@ -1,10 +1,57 @@
# Pricing Policy
## Customer training
## Discounts
The prices for the customers are fixed prices and not negotiable. Only prices and discounts mentioned in the pricing policy and in the IT system are approved. Deviations from this pricing policy must be approved by the CEO.
## Hourly invoicing
Hourly rates must get invoiced in 15 minute increments.
## Training
| Type | Costs |
| --------------------------------- | --------- |
| Customer administrator / Key-User | 100 EUR/h |
| End-User | 80 EUR/h* |
| Third party developer | 150 EUR/h |
> \* Free hours from the maintenance contract can be used if the customer has a maintenance contract available.
## Setup & configuration
| Type | Costs |
| ------------------------------------------------------------ | --------- |
| Support with setup of virtual environment | 300 EUR |
| Installation and configuration of software in virtual environment | 500 EUR |
| Installation and initial configuration of main application (incl. purchased modules) | 300 EUR |
| Installation and initial configuration of additional modules | 80 EUR/h* |
> \* Free hours from the maintenance contract can be used if the customer has a maintenance contract available.
## Data migration
## Support & maintenance fees
| Competency requirement | Maintenance Contract | No Maintenance Contract |
| ---------------------- | -------------------- | ----------------------- |
| 1st level | 80 EUR/h* | 100 EUR/h |
| 2nd level | 120 EUR/h | 150 EUR/h |
| 3rd level | 200 EUR/h | 250 EUR/h |
> \* Free hours from the maintenance contract can be used if the customer has a maintenance contract available.
## Support & maintenance
| Available hours | Maintenance Contract | No Maintenance Contract |
| ----------------------- | -------------------- | ----------------------- |
| Free hours available | 0 EUR/h | N.A. |
| No free hours available | 80 EUR/h | 100 EUR/h |
> N.A. = Not available.
## Customization
| Type | Maintenance Contract | No Maintenance Contract |
| ------------------------------------- | -------------------- | ----------------------- |
| Theme design | 80 EUR/h | 100 EUR/h |
| Application development/customization | 120 EUR/h | 150 EUR/h |
| Module customization | 120 EUR/h | 150 EUR/h |

42
Processes/01_Development.md
View File

@ -10,9 +10,9 @@ Every organization member and contributor to the organization must follow the [c
## Becoming a contributor
For public repositories you can immediately start by creating forks and pull requests. For private repositories which are necessary to setup the complete developer environment, feel free to request access. Please not that we may not immediately give you access to private repositories and instead will give you smaller tasks regarding public repositories. Please contact spl1nes.com@googlemail.com for more details. (R1)
For public repositories you can immediately start by creating forks and pull requests. For private repositories which are necessary to setup the complete developer environment, feel free to request access. Please not that we may not immediately give you access to private repositories and instead will give you smaller tasks regarding public repositories. Please contact spl1nes.com@googlemail.com for more details. (**R1**)
For all contributions our [Contributor License Agreement ("CLA")](https://github.com/Karaka-Management/Organization-Guide/blob/develop/legal/individual contributor license agreement.md) comes into effect. (R2)
For all contributions our [Contributor License Agreement ("CLA")](https://github.com/Karaka-Management/Organization-Guide/blob/develop/legal/individual contributor license agreement.md) comes into effect. (**R2**)
## Code changes
@ -20,36 +20,45 @@ For all contributions our [Contributor License Agreement ("CLA")](https://github
Generally, the development philosophy is result orientated. This means that anyone can propose tasks, pick up existing tasks or right away implement their code changes. However, implementing code changes without consulting with a senior developer in advance has a much higher risk of code changes not getting admitted. The easiest way to discuss a code change idea in advance are the github [issues](https://github.com/Karaka-Management/Karaka/issues) or [discussions](https://github.com/Karaka-Management/Karaka/discussions).
Developers are encouraged to pick open tasks with high priorities according to their own skill level. Senior developers may directly assign tasks to developers based on their importance. New developers may find it easier to start with a task that has a low priority as they often also have a lower difficulty.
Developers are encouraged to pick open tasks with high priorities according to their own skill level. Senior developers may directly assign tasks to developers based on their importance. New developers may find it easier to start with a task that has a low priority as they often also have a lower difficulty.
Open tasks can be found in the project overview: [PROJECT.md](https://github.com/Karaka-Management/Organization-Guide/blob/master/Project/PROJECT.md)
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.
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.
| Objective | Target | Achieved |
| -------------------------------- | ------------------------------------------------------------ | -------- |
| Tasks & todos get solved | > 100 tasks/todos get solved per year | YES |
| Milestones are completed on time | > 80% of all milestones are completed with less than 20% delay | YES |
### Quality
#### Code style
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 changes must follow the [style guidelines](https://github.com/Karaka-Management/Developer-Guide/tree/develop/standards) (**R3**). 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. (**R4**)
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. (R3)
In rare cases errors, failures or warnings during the automatic inspection are acceptable. Reasons can be for example special cases which are difficult automatize 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. (**R5**)
Automated checks which are run during the review process:
Automated checks which are run during the review process (**R4**):
```sh
php ./vendor/bin/phpcs ./ --standard="Build/Config/phpcs.xml"
npx eslint ./ -c ./Build/Config/.eslintrc.json
```
| Objective | Target | Achieved |
| --------------------- | ---------------------------------------------------------- | -------- |
| Consistent code style | < 10 code style errors exist in the latest release version | YES |
#### 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.
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) (**R6**). 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. (**R7**)
In rare cases it might be not possible to follow the inspection guidelines. In such cases the senior developer performing the code review may decide if the code change still gets accepted.
In rare cases it might be not possible to follow the inspection guidelines. In such cases the senior developer performing the code review may decide if the code change still gets accepted. (**R8**)
Automated tests which are run during the review process:
Automated tests which are run during the review process (**R7**):
```sh
php ./vendor/bin/phpunit -c tests/PHPUnit/phpunit_default.xml
@ -58,7 +67,12 @@ npx jasmine-node ./
./cOMS/tests/test.sh
```
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. (R4)
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. (**R7**)
| Objective | Target | Achieved |
| -------------------------- | -------------------------------- | -------- |
| Code is tested | > 90% code coverage is achieved | YES |
| Code tests are successfull | 100% of all tests are successful | YES |
#### Code review
@ -66,11 +80,11 @@ In addition to the automatic code review performed by the various inspection too
In case a code change request is not approved the reviewer states the reason for the decision, this may include some tips and requests which will allow the contributor to make improvements so that the code change may get approved.
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. (R3+R4)
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. (**R5**+**R8**)
#### 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. (R4)
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. (**R9**)
### Release flow
@ -87,7 +101,7 @@ The name of the branch can be chosen freely however it is recommended to follow
* `security-*` for security related fixes/improvements
* `general-*` for general improvements (i.e. code documentation improvements, code style improvements)
The senior developer who performs the code review merges the change request into the `develop` branch upon approval.
The senior developer who performs the code review merges the change request into the `develop` branch after their successful code review. Unsuccessful reviews lead to change requests by the original developer, other developers who can make the requested changes, changes by the senior developer who performed the review, or dismissal of the changed code. (**R10**)

1
Processes/01_Development_Flowchart.md
View File

@ -21,3 +21,4 @@ graph TD;
FIX-->TEST_CHANGE;
```
2022-01-01 - Version 1.0

10
Processes/01_Development_Risk Control Matrix.md
View File

@ -4,8 +4,14 @@
| ---- | ----------------- | ------------------------------ | ------------------------------------------------------------ | ---- | ---- | ----------------- | ---------------------------- | ------------------------------------------------------------ | ---- | ---- | ------- | ------------------------------------------------------------ | ---- | ---- |
| 1 | CTO | Operational Risk (Development) | Unauthorized source code and development asset access. | 1 | 1 | Many times a day | Preventing (System & Manual) | Only authorized people gain access to confidential source code and development assets. | 1 | 1 | | Not all source code and development assets are considered confidential and may be publicly accessible. The confidential aspects are determined by the CTO. | yes | yes |
| 2 | CTO | Operational Risk (Development) | Undefined terms of intellectual property for code contributions. | 1 | 3 | Many times a day | Preventing (Manual) | The terms of intellectual property for all contributions are well defined. | 1 | 1 | | | yes | yes |
| 3 | CTO/Code reviewer | Operational Risk (Development) | Inconsistent code styles (which increases frictions between developers) | 5 | 1 | Many times a day | Preventing (System & Manual) | Code styles are automatically tested with code style checkers. | 2 | 1 | | Not all code style options can be reasonably checked and defined. In some cases it's also possible to have false positive code style violations for edge cases. Manual checks during the code review by the responsible person may lead to additional code style changes or ignoring some code style "violations" if deemed reasonable. | yes | yes |
| 4 | CTO/Code reviewer | Operational Risk (Development) | Faulty code due to code changes, additions, removal. | 5 | 4 | Many times a day | Preventing (System & Manual) | Static code analysis tools and written tests for automatic tests. Additionally, manual tests can be performed in a demo environment with self generated dummy data. | 2 | 1 | | | | |
| 3 | Developer | Operational Risk (Development) | Inconsistent code styles (which increases frictions between developers) | 5 | 1 | Many times a day | Preventing (Manual) | Code style definitions are publicly available. | 2 | 1 | | | yes | yes |
| 4 | CTO/Code reviewer | Operational Risk (Development) | Inconsistent code styles (which increases frictions between developers) | 5 | 1 | Many times a day | Preventing (System & Manual) | Code styles are automatically tested with code style checkers. Optionally on the developer side but mandatory and automatic during the code merging. | 2 | 1 | | | yes | yes |
| 5 | CTO/Code reviewer | Operational Risk (Development) | Inconsistent code styles (which increases frictions between developers) | 5 | 1 | Many times a day | Preventing (Manual) | Code styles are checked which allows handling exceptions and special cases. | 2 | 1 | | Not all code style options can be reasonably checked and defined. In some cases it's also possible to have false positive code style violations for edge cases. Manual checks during the code review by the responsible person may lead to additional code style changes or ignoring some code style "violations" if deemed reasonable. | yes | yes |
| 6 | Developer | Operational Risk (Development) | Faulty code due to code changes, additions, removal. | 5 | 1 | Many times a day | Preventing (Manual) | Code testing definitions are publicly available. Minimum line coverage forces developers to write at least a certain amount of tests to check their code. | 2 | 1 | | | yes | yes |
| 7 | CTO/Code reviewer | Operational Risk (Development) | Faulty code due to code changes, additions, removal. | 5 | 1 | Many times a day | Preventing (System & Manual) | Code tests are automatically run with testing tools. Optionally on the developer side but mandatory and automatic during the code merging. This includes static tests which require no self-written tests and developer written tests. | 2 | 1 | | | yes | yes |
| 8 | CTO/Code reviewer | Operational Risk (Development) | Faulty code due to code changes, additions, removal. | 5 | 1 | Many times a day | Preventing (Manual) | Code tests are manually checked and performed which allows handling exceptions and special cases. | 2 | 1 | | | yes | yes |
| 9 | CTO/Code reviewer | Operational Risk (Development) | Faulty code due to code changes, additions, removal. | 5 | 4 | Many times a day | Preventing (Manual) | A demo application allows code reviewer to test code changes from a end-user point of view in conjunction with the whole application, other modules and dummy data. | 2 | 1 | | | yes | yes |
| 10 | CTO/Code reviewer | Operational Risk (Development) | Unauthorized code gets accepted. | 5 | 2 | Many times a day | Preventing (System+Manual) | Manual and automatic code checks/tests and manual review by authorized and qualified developers ensures high quality and that only code authorized by these developers gets accepted. Developers who can accept code changes are carefully selected and their permissions are handled in the version control software. | | | | | yes | yes |

52
Processes/02_Purchase.md
View File

@ -2,11 +2,11 @@
## Inquiry / Offer
Before purchasing employees must perform some research depending on the type and purchase amount. Generally, employees should always compare prices and also different vendors. For purchases above 1,000 EUR for single unit prices or above 50,000 EUR for total invoice expenses employees must always compare prices, argue why they choose a certain product and vendor and provide evidences of such research. Sometimes it can be applicable to not only compare different vendors but also different product types. This research may require to already request offers from potential suppliers and perform negotiations. Please use the **Investment Form**. (R1)
Before purchasing employees must perform some research depending on the type and purchase amount. Generally, employees should always compare prices and also different vendors. For purchases above 1,000 EUR for single unit prices or above 50,000 EUR for total invoice expenses employees must always compare prices, argue why they choose a certain product and vendor and provide evidences of such research. Sometimes it can be applicable to not only compare different vendors but also different product types. This research may require to already request offers from potential suppliers and perform negotiations. Please use the **Investment Form**. (**R1**)
## Offer approval
## Offer/Order approval
The approval of offers must be performed according to the below mentioned approval table. The approval is done by signature on the offer with date. (R2)
The approval of offers and orders must be performed according to the below mentioned approval table. The approval is done by signature on the offer/order with date. (**R2**)
### Approval table
@ -21,15 +21,17 @@ The approval of offers must be performed according to the below mentioned approv
## Purchasing
Only if a offer/order is approved by the authorized employees a purchase can be made. (**R3**)
The purchasing department creates an order in the IT system referring to the offer if available and forwards this order to the supplier.
For small orders below 1,000 EUR which are done at online shops or direct purchases in local shops no order in the IT system must be made. The reason for this is to increase efficiency for minor invoices. For purchases in local shops it's also not necessary that the purchase department itself does the purchasing but another department may do them.
For small orders below 1,000 EUR which are done at online shops or direct purchases in local shops no order in the IT system must be made. The reason for this is to increase efficiency for minor invoices. For purchases in local shops it's also not necessary that the purchase department itself does the purchasing but another department may do them. (**R3**)
All documents related to the purchasing process (i.e. offers, negotiation documentation, order confirmations, invoices etc.) must be stored in the IT system and referred to the respective purchase.
All documents related to the purchasing process (i.e. offers, negotiation documentation, order confirmations, invoices etc.) must be stored in the IT system and referred to the respective purchase. (**R4**)
## Supplier invoice validation
The invoice from the supplier must be stored in the IT system where it must be validated by the system. The system validates the following aspects:
The invoice from the supplier must be stored in the IT system where it must be validated by the IT system. The system validates the following aspects (**R5**):
* Valid and correct VAT ID
* VAT amounts and percentages mentioned on the invoice
@ -39,18 +41,46 @@ The invoice from the supplier must be stored in the IT system where it must be v
* Individual prices (if available in the order)
* Individual items on the invoice (if available in the order)
In case of differences the head of the department the order was performed for and the head of purchasing in the IT system must approve the differences.
In case of differences the head of the department the order was performed for and the head of purchasing in the IT system must approve the differences. (**R5**)
All invoices must be approved by the purchase employee handling the invoice. (R3)
All invoices must be approved by the purchase employee handling the invoice. (**R6**)
## Accounting
### Booking
The it system generates a booking suggestion for the invoice. This suggestion is based on automatic invoice recognition and manually trained system behavior (see accounting process for more details). The accountant booking the invoice can adjust the booking suggestion. Reasons for this can be a new business case, the booking suggestion must be split between multiple accounts, cost centers or cost objects which didn't get recognized or defined during the purchasing step.
The it system generates a booking suggestion for the invoice (**R7**). This suggestion is based on automatic invoice recognition and manually trained system behavior (see accounting process for more details). The accountant booking the invoice can adjust the booking suggestion. Reasons for this can be a new business case, the booking suggestion must be split between multiple accounts, cost centers or cost objects which didn't get recognized or defined during the purchasing step.
The IT system generates a monthly booking list with all invoices and their booking. The head of finance has to perform random checks on this list and approve the list in the IT system.
The IT system generates a monthly booking list with all invoices and their booking. The head of finance has to perform random checks on this list and approve the list in the IT system. (**R8**)
### Payment
The accountant starts the payment process by telling the IT system to generate a list of all payment suggestions according to the invoice payment terms. The system automatically calculates cash back and forex differences. The accountant may add or remove invoices from the suggestion. Both the accountant and the head of finance sign off on the payments in the IT system.
The accountant starts the payment process by telling the IT system to generate a list of all payment suggestions according to the invoice payment terms (**R9**). The system automatically calculates cash back and forex differences (**R10**). The accountant may add or remove invoices from the suggestion (**R11**). Both the accountant and the head of finance sign off on the payments in the IT system. (**R12**)
## Sub Processes
### New supplier
If a supplier is not in the IT system the supplier must be added. The following information must be added to the IT system (**R13**):
* Full company name incl. legal form
* VAT ID if available
* Address
* Contact information
* Main phone number
* Main email address
* Name of main contact person if available
> These information can be often found on the website (e.g. contacts, impressum) or on the letter head of invoices etc.
Adding additional information is often helpful.
The IT system is performing a credit score check, a sanction check and a VAT ID check (if available) in the background (**R14**). If these fail the purchasing department is automatically informed to check the supplier and make changes or manually approve the new supplier (**R15**). Only after the approval of the supplier orders can be created for that supplier in the IT system. (**R16**)
### Regular supplier checks
Once a day every supplier is automatically checked against sanction lists. (**R17**)
2022-01-01 - Version 1.0

1
Processes/02_Purchase_Flowchart.md
View File

@ -37,3 +37,4 @@ graph TD;
STAGE_4--Yes-->ORDER
```
2022-01-01 - Version 1.0

146
Processes/03_Sales.md
View File

@ -1,12 +1,10 @@
# Sales
# Sales
The organization has approx. XXX customers with X% located in Germany, Y% in other European countries and Z% in other countries. The customer acquisition is mostly done through online and print marketing. Online marketing consists of the own website and advertisement through various online services such as google, faceboox, linkedin, etc. Print marketing consists of occasional advertisements in print media such as ????.
## Offer for customer
When making offers to customers the following aspects should always be included in the first offer unless the customer explicitly requested the sales employee to not mention them on the invoice:
When making offers to customers the following aspects should always be included in the first offer unless the customer explicitly requested the sales employee to not mention them on the invoice (**R1**):
* The product the customer is interested in
* Product installation and configuration
@ -16,44 +14,148 @@ When making offers to customers the following aspects should always be included
* Payment terms:
* Generally, 10 days after invoice
* Maintenance contracts are invoiced for 12 months in advance
* Offers must be always non-binding
Offers must be created in the IT system. In the IT system various default offers are available which can be copied and modified if applicable to create an offer. If no applicable default offer is available individual offers can be created.
Offers must be created in the IT system (**R2**). In the IT system various default offers are available which can be copied and modified if applicable to create an offer (**R3**). If no applicable default offer is available individual offers can be created.
Prices and discounts must follow the pricing policy. Deviations from this pricing policy must be approved by the CEO.
Prices and discounts must follow the pricing policy (**R4**). Deviations from this pricing policy must be approved by the CEO (**R5**).
Offers can be edited as long as they are not delivered to the customer (or marked as delivered). (**R6**)
## Order from customer
After receiving the order from the customer the following aspects must be checked manually from the order by the sales department (**R7**):
* Is the order binding?
* Is the order consistent with a previous offer or the standard prices and products offered?
* Is the order done by authorized personnel (e.g. CEO, authorized officer)?
* Are all documents available (e.g. if the customer requests a maintenance contract this contract must be signed, signed data protection policy, ...)
If an order arrives through the online shop no manual checks must be performed because they are guaranteed through the IT system / online forms. In such a case the order is automatically approved. (**R8**)
## Order confirmation for customer
## Setup
Before creating a order confirmation the sales employee has to check if the order from the customer is approved (**R9**). Afterwards the sales employee can create a order confirmation which must be approved by a sales manager in the IT system. Only after the approval of the sales manager the order confirmation can be printed or sent via email. (**R10**).
If the order came from the online shop no manual interaction is necessary and the IT system automatically generates the order confirmation for the customer. (**R11**).
Order confirmations can be edited as long as they are not delivered to the customer (or marked as delivered). (**R12**).
## Delivery
Invoices can be edited as long as they are not delivered to the customer (or marked as delivered) (**R11**).
### Manual delivery/setup
Some products either require manual "*delivery*" or the customer requests manual "*delivery/setup*". Examples are customer training, customization, support during the setup or configuration process, etc.
In such a case the sales department coordinates with the necessary departments and the customer the delivery of the requested product or service.
### Automatic delivery/setup
Many products can be delivered automatically and immediately. Examples are license upgrades or continuation, maintenance contract term extension, software extension/modules, etc. which the user can install by themselves if they choose so.
In such a case the IT system automatically delivers the order. For licenses, contracts etc. the IT system adjusts the stored conditions for the customer. For software the IT system provides access or download links to the purchased software.
## Invoice for customer
## Booking
Invoices can be manually or automatically printed and send per mail, manually generated as PDF and manually or automatically send per e-mail depending on the customer settings.
## Payment collection
### Invoice contents
## Acquisition
Deviations to the pricing policy which is stored in the IT system are automatically recognized by the system and must be approved by the CEO before the invoice can be generated (**R12**).
### Prospect Initiated
Taxes on invoices are automatically calculated according to the customer settings and the ordered products and services (**R13**). Changes to taxes must be approved in the IT system by an accounting employee from the accounts receivable department. Without such an approval the invoice cannot be generated. (**R14**)
### Karaka Initiated
### Manual delivery/setup
## Offer
After the *delivery/setup* the sales department issues the invoice to the customer. The system imports the information from the order confirmation and generates a invoice for the customer. If manual adjustments need to be made compared to the original order confirmation a sales manager has to approve these changes in the IT system. (**R15**)
## Contracts
### Automatic delivery/setup
## Order Confirmation
### Credit Check
## Delivery Note
## Invoice
## Collection
In such a case the invoice is automatically and immediately generated by the IT system after the delivery of the order. (**R15**)
## Accounts Receivables
### Booking
The booking of invoices is automatically performed by the IT system after the delivery of the invoice to the customer. The correct accounting period, accounts, descriptions, taxes, cost centers, etc. are automatically generated by the IT system based on the customer settings, invoice settings as well as product and service settings. (**R16**)
### Collection
In case a customer doesn't pay their invoice according to the payment terms they receive up to 3 reminders:
| Type | Charge / fee |
| --------------- | -------------------------------------------- |
| First reminder | 0 EUR |
| Second reminder | 0.5% reminder fees (max. 150 EUR) |
| Last reminder | additional 0.5% reminder fees (max. 150 EUR) |
Payment reminders are generated by the IT system every 2 weeks (**R17**). The accountants responsible for the reminders can choose to exclude individual invoices and reminders. This can be helpful if invoices are challenged and need to get clarified. (**R18**)
If a customer doesn't pay after the 3rd invoice they are handed over either to a lawyer for collection through legal means, sold to third parties for collection or booked as loss on bad debts. The decision for the steps taken must be made by the head of finance. (**R19**)
If a customer pays during one of the three reminders he may continue to purchase products and services from the organization. If the customer only pays after the hand off to a lawyer etc. the head of finance may decide if the customer can continue to purchase from the organization. If the customer doesn't pay or declares insolvency no further purchases are allowed by the customer. (**R20**)
### Payment
The IT system automatically tries to match the payments to unpaid accounts receivables and/or customers based on the provided information from the payment (**R21**). The accounts receivable accountant responsible for booking customer payments has to approve or adjust the IT system suggestions (**R22**).
#### Credit Card
#### Paypal
#### Wire transfer
#### Direct debit
## Sub Processes
### New customer
If a customer is not in the IT system the customer must be added. The following information must be added to the IT system (**R23**):
* Full company name incl. legal form
* VAT ID if available
* Address
* Contact information
* Main phone number
* Main email address
* Name of main contact person if available
* Invoicing type (e.g. email or mail)
> These information can be often found on the website (e.g. contacts, impressum) or on the letter head of customer etc.
Adding additional information is often helpful. If a customer makes a order online these information are requested on the website and the customer must provide them before the website submits the order.
The IT system is performing a credit score check, a sanction check and a VAT ID check (if available) in the background (**R24**). If these fail the sales department is automatically informed to check the customer and make changes or manually approve the new customer (**R25**). Only after the approval of the customer offers, order confirmations, invoices, etc. can be created for that customer in the IT system (**R26**).
### Regular customer checks
Once a day every customer is automatically checked against sanction lists. (**R27**)
### Customer acquisition
#### Prospect initiated
Most prospect or customer initiated acquisition comes from one of the following main marketing measures:
* online advertisements
* website / shop
* search engines
* social media advertisement
* occasional advertisement in professional journals depending on the target group
#### Karaka initiated
##### Purchased contact information
The organization occasionally purchases contact addresses (email & mail addresses) which get contacted (cold acquisition).
##### Events
The organization occasionally visits events where it holds presentations with various topics. Additionally, the organization sometimes has a booth at trade fairs, seminars etc. where it presents their products.
2022-01-01 - Version 1.0

24
Processes/03_Sales_Flowchart.md
View File

@ -0,0 +1,24 @@
# Sales Flowchart
```mermaid
graph TD;
OFFER([Offer to customer])-->ORDER[Order from customer];
ORDER-->VALID_ORDER{Is valid?};
VALID_ORDER--YES?-->ORDER_CONFIRMATION[Order confirmation];
ORDER_CONFIRMATION-->DELIVERY[Delivery to customer];
DELIVERY-->INVOICE[Generate invoice];
INVOICE-->BOOKING[Booking invoice];
BOOKING-->PAYMENT{Customer pays?};
PAYMENT--YES?-->BOOKING_PAYMENT[Book payment];
PAYMENT--NO?-->REMINDER[Create reminder];
REMINDER--3-->PAYMENT;
REMINDER-->LAWYER[Collection with lawyer];
REMINDER-->SELL_RECEIVABLE[Sell receivables];
REMINDER-->BAD_DEBT[Loss on bad debt];
LAWYER-->LAWYER_PAID{Customer pays?};
LAWYER_PAID--YES?-->BOOKING_PAYMENT;
LAWYER_PAID--NO?-->BAD_DEBT;
```
2022-01-01 - Version 1.0

38
Processes/04_Support & Service.md Normal file
View File

@ -0,0 +1,38 @@
# Support & Service
Support or any other software related services are only allowed if the customer has signed the [Customer Data Protection Policy]() and the [Customer Service Agreement](). This ensures that customer data access is legally and contractually covered. The customer Customer Service Agreement regulates the responsibilities and liabilities.
## Data migration
The customer and the support employee need to define the exact goals, data structure and migration strategy before it can be executed. These definitions must be put on the offer for the customer including a cost evaluation based on the time needed to perform the data migration and the complexity of the data migration.
Only after the binding approval by the customer the order confirmation will be created (see sales process) and then the data migration can be performed.
## Setup & configuration
### Virtual environment
### Software installation and configuration on virtual environment
### Main application
### Modules
## Customization
## Training
### Customer administrator / Key-User
### End-User
### Third party developer
## Maintenance
## Support
2022-01-01 - Version 1.0

5
Processes/04_Support & Service_Flowchart.md Normal file
View File

@ -0,0 +1,5 @@
# Support & Service Flowchart
2022-01-01 - Version 1.0

6
Processes/04_Support & Service_Risk Control Matrix.md Normal file
View File

@ -0,0 +1,6 @@
# Support & Service Risk Control Matrix
2022-01-01 - Version 1.0

13
Processes/04_Support.md
View File

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

185
Processes/05_HR.md
View File

@ -1,13 +1,180 @@
# Payroll
# HR
| No. | Process step | Risks/Things to consider | Checks/Risk mitigation | R | O |
| ---- | ------------ | ------------------------ | ---------------------- | ---- | ---- |
| | | | | | |
| | | | | | |
| | | | | | |
## Hiring
Abbreviations:
| KPI | Target | Achieved |
| ------------------------------------------------------ | --------------------------------------------- | -------- |
| Fill HR positions quickly and with qualified personnel | > 80% filled vacant positions during the year | YES |
| Keep HR costs reasonable | Stay within HR budget | YES |
* R: Responsible
* O: Occurrence
### Search
#### Approval
Before searching for a new employee the search must be approved by the head of HR, an executive staff member who is legally allowed to hire employees or the CEO (**R1**). Generally, employees may only get hired in case of (**R2**):
* Replacement
* Budgeted new position
* Changes in the organization which requires not budgeted hiring
The approval for the employee search must be in writing and can be done the IT system or by using the [Employee Search Form](./HR/Hiring/Employee%20Search%20Form.md).
#### Employment ad
Every employment ad must be posted on the own website, internally through the Intranet, on the black board in the company location(s) and the agency for labor (Agentur für Arbeit) (**R3**). Additionally, employment ads may be placed on online job portals. The job portals can be chosen by the HR department, important criteria are the size of the job portal and the target group who visits these job portals. The contact address for applicants is the HR department.
The standard PDF layout for job postings can be found in the Job [Posting Layout_**.docx](./HR/Hiring/Posting%20Layout_en.docx) file. Different language files are available. (**R4**)
#### Head hunter & HR search agency
The search with a search agency should be none exclusive and paid based on success. Searching with a head hunter should be the last option or primarily get used for the search of head of departments or managers (**R5**). The search with a head hunter can be exclusive. As a basis for their search they must receive the job posting which is also published internally, additional information such as the preferred salary (not max salary) should be provided as well.. The contact for the head hunter and the search agency is the HR department.
### Application
All applications must be reviewed by the HR department. The HR department may immediately exclude applications in case of salary requests above the maximum acceptable salary and applications of applicants which obviously don't match the job description (**R6**). Some deviations between the applicants haves and the job posting haves are acceptable (**R7**).
The applications must get anonymized (name, address, nationality, gender, image, etc.) by the HR department, possible salary figures must also get removed. The anonymized application is forwarded by the HR department to the responsible person for review (e.g. head of department, executive member, CEO, ...). (**R8**)
#### Rejection
In case of a application rejection the HR department should give a timely response to the applicant. The rejection text must be the [Default Rejection](./HR/Hiring/Default%20Rejection.md) text. (**R9**)
#### Interviews
Candidates selected by the responsible person (often the head of the department or executive staff member who initiated the hiring process) for interviews must be returned to the HR department with a remark "*to be interviewed*" or similar. Candidates who are deemed to be unfit must be returned to the HR department with a remark "*to be rejected*" or similar. No copies of the application must remain in the position of the responsible person (emails must be deleted).
The HR department handles the applications according the remark by the responsible person. The HR department checks in the sanctions software the accepted applicant against sanctions and If an applicant is sanctioned in a way which doesn't allow or doesn't make an employment feasible the applicant must be rejected by the HR department. (**R10**).
The HR department must take notes during the interview process and also make sure that all necessary aspects for a potential contract are clarified (e.g. salary, vacation, job description, work conditions, ...). These notes must be forwarded to the person creating the contract.
The interview process is defined as follows:
##### Employee
| Interview | Interview type | Participants / selection committee |
| ------------------------------------------------------ | --------------- | ------------------------------------------------------ |
| First interview (only in case of external application) | Phone or online | Responsible person (or alternatively HR department) |
| Second interview | In person | Responsible person + one person from the HR department |
| Third interview | In person | Responsible person + one person from the HR department |
Final decision if no majority vote can be found during the application selection: CEO.
##### Head of department / manager
| Interview | Interview type | Participants / selection committee |
| ------------------------------------------------------ | --------------------------------------------- | ------------------------------------------------------------ |
| First interview (only in case of external application) | TBD | Head hunter / HR search agency (no voting rights) |
| Second interview | Phone or online (unless internal application) | Responsible person + one person from the HR department |
| Third interview | In person | Responsible person + CEO/Executive staff member(s) + one person from the HR department |
Final decision if no majority vote can be found during the application selection: CEO or the executive staff member if the CEO wasn't partaking.
#### Reference check
The HR department has to check the references of an applicant latest before the third interview. This includes checking some previous employment references if applicable. Certificates and educational credentials must only be checked if they seem illegitimate. (**R11**)
#### Applicant selection
The selection of a applicant should be done based on the following criteria:
- [x] The applicant fits the job description sufficiently.
- [x] The applicant fits into the team.
- [x] The applicant had positive interviews / managed to present themselves with sufficient competence.
- [x] The salary of the applicant is within budget / below the max. acceptable salary.
- [x] The applicant fits other criteria which are not mentioned in the job description?
- [x] The applicant is assumed to stay for at least 4 years in the company.
- [x] The applicant will not exceed the max. acceptable salary within 4 years.
- [x] The applicant doesn't have a criminal record or sanctions which don't allow their employment.
- [x] The contents of the application are true and applicant references are positive.
It is advised to compare multiple applicants with each other to find the best fit. However, in some situations this may not be possible due to the job market situation or low amount of applicants.
##### Voting
The final decision if an applicant should get hired after meeting the above mentioned requirements is the responsibility of the selection committee. The selection committee makes this decision based on a majority vote where every member of the selection committee has equal voting rights (**R12**). Sometimes additional participants can be present during interview processes, they have no voting rights. If different HR employees partake in the interview processes only one HR employee has voting rights (usually the HR employee with the highest position).
The result of the voting process is logged in the notes of the HR employee and must be signed by all members of the selection committee. (**R13**)
### Contract
The employment contract must be created by the HR department. The basis for the contract is the [Sample Contract](./HR/Hiring/Sample%20Contract.md) (**R13**), the job application, the [Employee Search Form](./HR/Hiring/Employee%20Search%20Form.md), conditions negotiated during the interview process. Before sending the contract to the applicant it must get approved by the head of HR (**R14**). Additional documents which must be signed and provided by the applicant are the NDA, CLA, privacy policy, criminal record certificate, tax id.
The following aspects must be considered and checked by the head of HR before the contract can be signed by authorized persons in the organization (**R15**).
- [x] The applicant in the contract got selected by the selection committee (**R15**)
- [x] Application contains credentials (**R15**)
- [x] Credentials are verified (**R15**)
- [x] Contract is signed by applicant (**R15**)
- [x] The signed contract is the approved version (unaltered) (**R15**)
- [x] NDA is signed (**R15**)
- [x] CLA is signed (**R15**)
- [x] Privicy policy is signed (**R15**)
- [x] Criminal record certificate (**R15a**) and no sanctions which prevent hiring (**R15b**)
- [x] Applicant tax id is available (**R15**)
- [x] Work permit is available (if necessary) (**R15**)
The employment contract must only get signed by an authorized persons in the organization (e.g. CEO, executive staff member, authorized officers). (**R16**)
### Training plan
The training plan must be finalized before the employee starts their employment. The head of the department where the employee will start is responsible for creating the training plan. The basis for the training plan is the [Sample Training Plan](./HR/Onboarding/Sample%20Training%20Plan.md) and the department specific tasks. (**R17**)
This training plan must get signed by the employee after completion in order to document the successful training. (**R18**)
### Employee file
Documents from the hiring process attached in the employee file are:
* Employee Search Form
* Application
* Credentials
* Signed contract
* Signed NDA
* Signed CLA
* Signed privacy policy
* Signed interview notes by the selection committee
* Criminal record certificate
* No sanctions evidence
* Tax id
* Work permit (if available)
* Hiring Checklist
* Signed training plan
## Payroll
| KPI | Target | Achieved |
| --------------------------- | ------------------------------------------------------------ | -------- |
| Employees are paid on time | 99% of the monthly salaries/wages are paid before the 1st of every month | YES |
| Reasonably low tax mistakes | Stay below 5,000 EUR tax corrections per year (only checked during wage audit every 3-5 years) | YES |
## Evaluation
| KPI | Target | Achieved |
| ------------------------------------------------- | ------------------------------------------------------------ | -------- |
| Regular performance review of employees | All employees receive a evaluation once a year | YES |
| Employees can communicate feedback to the company | All employees receive a company evaluation form once a year which they can anonymously submit | YES |
### Employee evaluation
The employee evaluations goal is to allow a supervisor to provide a formalized performance and qualification review to the employee. This evaluation must take place annually ideally during October 1st to October 31st between the supervisor and the employee (**R19**). Every supervisor must perform these employee evaluations based on the Employee Evaluation Form which needs to be signed by the supervisor after its discussion with the employee (**R20**).
The signed evaluation form must get handed over by the supervisor to the HR department who ensure that the employee also receives a copy. The HR department also must keep track of all completed employee evaluations and remind supervisors to to finish their employee evaluations if they are not completed in time. (**R21**)
### Self-Evaluation
Every employee must fill out the Self-Evaluation Form which the employee must sign and hand over to the supervisor during the employee evaluation. The purpose of the self-evaluation is to match the employees performance and qualification perception against the performance and qualification perceived by the supervisor (**R22**). Deviations between the self-evaluation and the evaluation by the supervisor must be discussed during the employee evaluation.
The self-evaluation must be handed over by the supervisor to the HR department after the employee evaluation.
### Company evaluation
Every year every employee receives a Company Evaluation Form which they can fill out and anonymously submit to the HR department (**R23**). These forms are evaluated and analyzed by the HR department to find improvements for the company. (**R24**)
### Regularly employee checks
Every employee is checked automatically every night against sanctions lists in the IT system (**R50**)
2022-01-01 - Version 1.0

59
Processes/06_Finance.md
View File

@ -16,6 +16,8 @@ The approval of the budget is handled by the management and should be done until
If amendments need to be made the management may approve a preliminary budget until the actual budget is finalized and approved. Examples for a preliminary budget could be the approval to work according to the budget for the first month but adjust the budget for the remaining 11 months. Another solution could be to work according to the budget of the previous year until the new budget got adjusted. The decision how the interim period until the budget is corrected and approved should be handled based on the decision of the management.
The tasks and responsibilities can be found in the Budgeting Checklist. The checklist must be signed by every responsible person after completing the defined task.
### Forecast
The basis of many figures and KPIs for the budgeted periods is the current fiscal year. For this reason the current fiscal year must be forecasted during the budgeting process. Information regarding the forecast should be collected in a similar way as for the budget figures.
@ -38,8 +40,6 @@ For the budget the gross profit margins per product group must be used. A total
#### OPEX
Responsible: Finance + Management
Operating expenses must contain the following information:
* Costs per account
@ -56,8 +56,6 @@ The following budget positions must be budgeted from the respective head of the
##### HR
Responsible: HR + Finance + Management
The HR budget must contain the budget for every employee and all replacements as well as new budgeted positions. The HR budget should also be done per salary type. This also allows to accumulate the HR budget per department/cost center and compare changes with previous years.
Planned salary increases should be already included in the budget (e.g. individual salary increases, general inflation increases, performance related increases, ...).
@ -69,8 +67,6 @@ The following general adjustments should be included in the total budget:
##### Marketing
Responsible: Marketing + Finance + Management
The marketing budget must contain the budget for the different marketing types:
* Print media
@ -80,8 +76,6 @@ The marketing budget must contain the budget for the different marketing types:
#### Investments
Responsible: Finance + Management
##### Depreciations
Depreciations are calculated based on the existing assets and their depreciation amounts/lifetime as well as the depreciation amounts and lifetime of new investments. Small new investments don't have to be calculated individually but can be calculated in a compounded position if they have the same lifetime (i.e. all PCs, laptops, printer, ... together).
@ -93,3 +87,52 @@ Depreciations are calculated based on the existing assets and their depreciation
#### Taxes
The taxes should be estimated based on the EBIT and the local tax rate. Corrections regarding deductible and non-deductible expenses should be included as well.
## Monthly closing
### Deadline
The deadline is the 4th work day of the following month.
### Responsibilities
The tasks and responsibilities can be found in the Monthly Closing Checklist. The checklist must be signed by every responsible person after completing the defined task.
## Annual closing
### Deadline
The deadline is the 4th work day of the new fiscal year.
### Responsibilities
The tasks and responsibilities can be found in the Monthly Closing Checklist and additionally the Annual Closing Checklist. The checklists must be signed by every responsible person after completing the defined task.
## Annual financial audit
### Deadline
The deadline for the audit preparation is 3 days before the audit takes place.
### Responsibilities
The tasks and responsibilities can be found in the Annual Audit Checklist. The checklist must be signed by every responsible person after completing the defined task.
## Reporting
The reporting for the organization is done once a month and shared with different employees depending on authorities and responsibilities.
### Deadline
The deadline is the 5th work day of the following month.
### Responsibilities
The tasks and responsibilities can be found in the Monthly Reporting Checklist. The checklist must be signed by every responsible person after completing the defined task.
### Contents
2022-01-01 - Version 1.0

9
Processes/07_Management.md
View File

@ -1,13 +1,6 @@
# Management
| No. | Process step | Risks/Things to consider | Checks/Risk mitigation | R | O |
| ---- | ------------ | ------------------------ | ---------------------- | ---- | ---- |
| | | | | | |
| | | | | | |
| | | | | | |
Abbreviations:
* R: Responsible
* O: Occurrence
2022-01-01 - Version 1.0

5
Processes/08_Quality Management
View File

@ -1 +1,6 @@
# Quality Management
2022-01-01 - Version 1.0

17
Processes/Finance/Budgeting/Budgeting Checklist.md Normal file
View File

@ -0,0 +1,17 @@
# Budgeting Checklist
| Task | Responsible | Shared with | Signature | Date |
| ------------------------ | --------------------------------- | ------------------------------------------------------------ | --------- | ---- |
| Sales budget | Head of Sales | CEO + executive staff members + Head of Sales | | |
| Marketing budget | Head of Marketing + Head of Sales | CEO + executive staff members + Head of Marketing | | |
| HR budget | Head of HR | CEO + executive staff members + Head of HR + Head of Departments (headcount changes only) | | |
| Investment budget | CFO + Head of Departments | CEO + executive staff members + Head of Departments (department budget only) | | |
| Employee training budget | CFO + Head of Departments | CEO + executive staff members + Head of Departments (department budget only) | | |
| Other OPEX | CFO | CEO + executive staff members | | |
| Full income statement | CFO + CEO | CEO + executive staff members | | |
| Overall responsibility | CEO + CFO | | | |
2022-01-01 - Version 1.0

0
Processes/Finance/Budgeting Templates/Department Budget Template.md → Processes/Finance/Budgeting/Department Budget Template.md
View File

51
Processes/Finance/Financial Closing/Annual Audit Checklist.md Normal file
View File

@ -0,0 +1,51 @@
# Annual Audit Checklist
| Task | Responsible | Signature | Date |
| ------------------------------------------------------------ | --------------------- | --------- | ---- |
| Define audit schedule with auditors | Head of Finance | | |
| All account forms (e.g. GoBD files) | | | |
| Asset analysis | | | |
| Asset history sheet | | | |
| Sold assets | | | |
| New assets | | | |
| Capitalization basis of self-made assets | | | |
| Cash on hand ledger | | | |
| Bank confirmation of balance | | | |
| Customer confirmation of balance | | | |
| Supplier confirmation of balance | | | |
| Lawyer confirmation of balance | | | |
| Deferred credits to income | | | |
| Cut-off test for sales | | | |
| Cut-off test for supplier invoices | | | |
| Prepaid expenses and deferred charges | | | |
| Received prepayments | | | |
| Paid prepayments | | | |
| Accounts receivable and accounts payable with switching balance | | | |
| New important contracts | | | |
| Financial obligation | | | |
| Allowance for bad debts | | | |
| 30% entertainment booking | | | |
| Guarantee accruals | | | |
| HR accruals | | | |
| Annual wage journal | | | |
| CEO contract | | | |
| General invoice accruals | | | |
| Year-end accruals | | | |
| Tax calculations (local commercial tax and corporate income tax) | | | |
| Sales tax return / VAT return | | | |
| Deferred tax calculation | | | |
| Executive committee minutes | | | |
| Shareholder resolutions | | | |
| Commercial register | | | |
| Notes to the financial statement | | | |
| Management report | | | |
| Budget | | | |
| Internal control system | | | |
| Average employee count | | | |
| Audit report e.g. taxes (if available) | | | |
| Overall responsibility | Head of Finance + CFO | | |
2022-01-01 - Version 1.0

11
Processes/Finance/Financial Closing/Annual Closing Checklist.md Normal file
View File

@ -0,0 +1,11 @@
# Annual Closing Checklist
| Task | Responsible | Signature | Date |
| ----------------------------------- | --------------- | --------- | ---- |
| Define audit schedule with auditors | Head of Finance | | |
| | | | |
2022-01-01 - Version 1.0

12
Processes/Finance/Financial Closing/Monthly Closing Checklist.md Normal file
View File

@ -0,0 +1,12 @@
# Monthly Closing Checklist
| Task | Responsible | Signature | Date |
| ----------------------------- | --------------- | --------- | ---- |
| Verify bank balance | Head of Finance | | |
| Book general invoice accruals | | | |
| Book wages | | | |
2022-01-01 - Version 1.0

BIN
Processes/Finance/Reporting Templates/Financial Reporting.ods
View File

Binary file not shown.

BIN
Processes/Finance/Reporting/Financial Reporting.ods Normal file
View File

Binary file not shown.

26
Processes/Finance/Reporting/Monthly Reporting Checklist.md Normal file
View File

@ -0,0 +1,26 @@
# Monthly Reporting Checklist
| Task | Responsible | Shared with | Signature | Date |
| ------------------------------------------------------------ | --------------- | ----------- | --------- | ---- |
| Income statement incl. PY and budget figures | Head of Finance | | | |
| Income statement per product group (profit center) incl. PY and budget figures | Head of Finance | | | |
| Balance sheet | Head of Finance | | | |
| Sales analysis per product group incl. PY and budget figures | Head of Finance | | | |
| Sales analysis per sales rep. incl. PY and budget figures | Head of Finance | | | |
| Sales analysis per country incl. PY and budget figures | Head of Finance | | | |
| Long term sales development per product group | Head of Finance | | | |
| Long term sales development per sales rep. | Head of Finance | | | |
| Long term sales development per country | Head of Finance | | | |
| Long term active customer amount development | Head of Finance | | | |
| Long term sales per employee development | Head of Finance | | | |
| Long term EBIT per employee development | Head of Finance | | | |
| Long term customer ticket development | Head of Finance | | | |
| Long term open customer ticket development | Head of Finance | | | |
| Long term employee cost development per department incl. headcount | Head of Finance | | | |
| Long term free cash flow development | Head of Finance | | | |
| Status update on key projects and tasks | CTO + CFO | | | |
2022-01-01 - Version 1.0

21
Processes/HR/Evaluation Forms/Colleague Evaluation Form.md
View File

@ -1,21 +0,0 @@
# Colleague Evaluation Form
| No. | Topic | Very Confident | Fairly Confident | Not Very Confident | Not At All Confident | Notes |
| ---- | ----------------------------- | ---------------| ---------------- | ------------------ | -------------------- | ----- |
| 1 | My colleagues have a broad and deep knowledge overy my work field. | | | | | |
| 2 | My colleagues also considering my job/department when doing their work. | | | | | |
| 3 | My colleagues are flexible. | | | | | |
| 4 | My colleagues are motivated. | | | | | |
| 5 | My colleagues are good at communication. | | | | | |
| 6 | My colleagues share information with me accordingly. | | | | | |
| 7 | My colleagues are team players. | | | | | |
| 8 | My colleagues complete assigned work effectively and on time. | | | | | |
| 9 | My colleagues are resilient. | | | | | |
| 10 | My colleagues show initiative. | | | | | |
| 11 | My colleagues work autonomously. | | | | | |
2022-01-01 - Version 1.0

16
Processes/HR/Hiring/Default Rejection.md Normal file
View File

@ -0,0 +1,16 @@
# Default Rejection
Dear {NAME}
We appreciate your interest in our organization and the position of {POSITION} for which you applied. After reviewing the application, yours was not selected for further consideration.
The selection committee appreciates the time you invested in your application and wish you best of lock for your future endeavors.
Best regards,
{HR_EMPLOYEE_NAME}

19
Processes/HR/Hiring/Employee Search Form.md Normal file
View File

@ -0,0 +1,19 @@
# Employee Search Form
| Step | Parameter |
| ------------------------------------------------------------ | --------- |
| Position / Title | |
| Department | |
| Max salary | TBD by HR |
| Must haves | TBD by HR |
| Nice to have | TBD by HR |
| Search channels (e.g. only internal, online ad, head hunter) | TBD by HR |
| Position type (e.g. replacement, budgeted, not budgeted) | |
| Search approval by | |
> Positions can be empty (except the search approval) and to be defined (TBD) by HR.
2022-01-01 - Version 1.0

33
Processes/HR/Hiring/Hiring Checklist.md
View File

@ -1,19 +1,24 @@
# Hiring Checklist
| Topic | Date | By | Done |
| -------------------------------- | ---- | ------------- | ---- |
| Application contains a CV | | Head of HR | |
| Application contains credentials | | Head of HR | |
| Credentials are verified | | Head of HR | |
| Contract approved by head of HR | | Head of HR | |
| Contract is signed | | Head of HR | |
| NDA is signed | | Head of HR | |
| CLA is signed | | Head of HR | |
| Privicy policy is signed | | Head of HR | |
| Equipment is taken care of | | Head of IT | |
| Credentials are taken care of | | Head of IT | |
| Car is taken care of | | Fleet manager | |
| Training plan is taken care of | | Head of HR | |
| Topic | Date | By | Done |
| --------------------------------------------- | ---- | ------------- | ---- |
| Application contains a CV | | Head of HR | |
| Application contains credentials | | Head of HR | |
| Credentials are verified | | Head of HR | |
| Contract approved by head of HR | | Head of HR | |
| Contract is signed by applicant | | Head of HR | |
| Contract is the approved version (unaltered) | | Head of HR | |
| NDA is signed | | Head of HR | |
| CLA is signed | | Head of HR | |
| Privicy policy is signed | | Head of HR | |
| Criminal record certificate is negative | | Head of HR | |
| No sanctions which prevent hiring | | Head of HR | |
| Tax id of the applicant is available | | Head of HR | |
| Work permit is available (if necessary) | | Head of HR | |
| Equipment is taken care of | | Head of IT | |
| IT and building credentials are taken care of | | Head of IT | |
| Car is taken care of | | Fleet manager | |
| Training plan is taken care of | | Head of HR | |

BIN
Processes/HR/Hiring/Posting Layout_en.docx Normal file
View File

Binary file not shown.

19
Processes/HR/Onboarding/Sample Training Plan.md Normal file
View File

@ -0,0 +1,19 @@
# Sample Training Plan
| Training plan | Date | By |
| ------------------------------------------------------------ | ---- | ----------------------------- |
| Welcome at company | | HR |
| Handover of credentials | | HR |
| Handover of on boarding package | | HR |
| Company tour | | HR |
| Welcome and introduction at the department | | Head of department |
| Setup of work environment | | Head of department |
| Training of development tasks and guidelines incl. quality management aspects | | Development department |
| Training of support & quality tasks and guidelines incl. quality management aspects | | Support & Quality department |
| Training of quality management tasks and guidelines | | Quality Management department |
| Training of accounting tasks and guidelines | | Accounting department |
2022-01-01 - Version 1.0

26
Processes/Interdependency.md
View File

@ -1,11 +1,17 @@
# Interdependency
| | Development | Purchase | Sales | Management | Payroll | Inventory | Support & Service | Quality Management |
| - | - | - | - | - | - | - | - | - |
| Development |
| Purchase |
| Sales |
| Management |
| Payroll |
| Inventory |
| Support & Service |
| Quality Management |
| | Development | Purchase | Sales | Management | Support & Service | Quality Management | IT | Finance | HR | Marketing |
| - | - | - | - | - | - | - | - | - | - | - |
| Development | | | | | | |x||||
| Purchase || | | | | | x | | | |
| Sales ||||| ||x|||x|
| Management |||||||x||||
| Support & Service |x|| |||x|x||||
| Quality Management |x|||| x ||x||||
| IT | | | | | | | x | |||
| Finance ||x|x||||x|| x ||
| HR |||||||x|x|||
| Marketing ||| x | | | | x | | ||
2022-01-01 - Version 1.0

0
Strategy/Business Plan.md → Processes/Management/Business Plan.md
View File

0
Strategy/Marketing/Marketing Material.md → Processes/Marketing/Marketing Material.md
View File

0
Strategy/Marketing/Presentations/Pitching.pdf → Processes/Marketing/Presentations/Pitching.pdf
View File

0
Strategy/Marketing/Shop.md → Processes/Marketing/Shop.md
View File

3
Processes/Organigram.md
View File

@ -1,3 +1,5 @@
# Organigram
```mermaid
graph TD;
MANAGEMENT[Management]---DEVELOPMENT[Development];
@ -19,3 +21,4 @@ graph TD;
MARKETING---CSO
```
2022-01-01 - Version 1.0

0
Processes/04_Support_Flowchart.md → Processes/Sales/Customer Data Protection Policy.md
View File

0
Processes/04_Support_Risk Control Matrix.md → Processes/Sales/Customer Service Agreement.md
View File

0
Strategy/Key Selling Points.md → Processes/Sales/Key Selling Points.md
View File

2
Strategy/FAQ/Pitching.md → Processes/Sales/Pitching FAQ.md
View File

@ -1,4 +1,4 @@
# FAQ: Pitching
# Pitching FAQ
## General
* How long does this software exist in the market?