diff --git a/Processes/01_Development.md b/Processes/01_Development.md index 075c023..c529409 100644 --- a/Processes/01_Development.md +++ b/Processes/01_Development.md @@ -1,5 +1,13 @@ # Development +| Key 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 | +| Consistent code style | < 10 code style errors exist in the latest release version | YES | +| Code is tested | > 90% code coverage is achieved | YES | +| Code tests are successfull | 100% of all tests are successful | YES | + ## Development environment The setup and configuration of the development environment is in the hands of every developer themselves. However, it is recommended to follow the setup instructions in the [Developer-Guide](https://github.com/Karaka-Management/Developer-Guide/blob/develop/general/setup.md). @@ -28,11 +36,6 @@ Tasks currently in development are prefixed in the priority column with an aster 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 @@ -48,10 +51,6 @@ 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) (**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**) @@ -69,11 +68,6 @@ 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. (**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 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. diff --git a/Processes/01_Development_Risk Control Matrix.md b/Processes/01_Development_Risk Control Matrix.md index 69989b0..5c084ba 100644 --- a/Processes/01_Development_Risk Control Matrix.md +++ b/Processes/01_Development_Risk Control Matrix.md @@ -1,18 +1,34 @@ # Development Risk Control Matrix -| No. | R | Category | Risk Event | L | C | O | Mitigation Type | Mitigation Strategy | L* | C* | Changes | Comments | ES | EY | -| ---- | ----------------- | ------------------------------ | ------------------------------------------------------------ | ---- | ---- | ----------------- | ---------------------------- | ------------------------------------------------------------ | ---- | ---- | ------- | ------------------------------------------------------------ | ---- | ---- | -| 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 | 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 | +| No. | R | Category | Risk Event | L | C | O | Cause | Mitigation Type | Mitigation Strategy | L* | C* | Changes | Comments | ES | EY | +| ---- | ----------------- | ------------------------------ | ------------------------------------------------------------ | ---- | ---- | ----------------- | ----------------------------- | ---------------------------- | ------------------------------------------------------------ | ---- | ---- | ------- | ------------------------------------------------------------ | ---- | ---- | +| 1 | CTO | Operational Risk (Development) | Unauthorized source code and development asset access. | 1 | 1 | Many times a day | Unmanaged access permissions. | 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 | 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 | +## Abbreviations +* R: Responsible + +* L: Likelihood (1-5) + +* C: Consequence (1-5) + +* L\*/C\*: Likelihood and Consequence after mitigation + +* O: Occurrence (many times a day, daily, weekly, monthly, annually) + +* ES: Effective + +* EY: Efficient + + 2022-01-01 - Version 1.0 diff --git a/Processes/02_Purchase.md b/Processes/02_Purchase.md index e8ee185..e3c0e1a 100644 --- a/Processes/02_Purchase.md +++ b/Processes/02_Purchase.md @@ -1,8 +1,12 @@ # Purchase +| Key Objective | Target | Achieved | +| ---------------------- | ------------------------------------------- | -------- | +| High quality suppliers | Key suppliers have no severe quality issues | YES | + ## 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](Purchase/Investment%20Form.md). (**R1**) ## Offer/Order approval @@ -21,17 +25,17 @@ The approval of offers and orders must be performed according to the below menti ## Purchasing -Only if a offer/order is approved by the authorized employees a purchase can be made. (**R3**) +Only if a offer/order is approved by the authorized employees a purchase can be made. (**R2**) 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. (**R3**) +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. -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**) +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. (**R3**) ## Supplier invoice validation -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**): +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 (**R4**): * Valid and correct VAT ID * VAT amounts and percentages mentioned on the invoice @@ -41,27 +45,27 @@ 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. (**R5**) +All invoices must be approved by the purchase employee handling the invoice. (**R5**) -All invoices must be approved by the purchase employee handling the invoice. (**R6**) +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. (**R6**) ## Accounting ### Booking -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 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 (**R8**). 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. (**R8**) +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. (**R9**) ### 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 (**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**) +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 (**R10**). The system automatically calculates cash back and forex differences (**R11**). The accountant may add, remove and adjust invoices from the suggestion (**R12**). Both the accountant and the head of finance sign off on the payments in the IT system which also shows added, removed and adjusted payments. (**R13**) ## 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**): +If a supplier is not in the IT system the supplier must be added. The following information must be added to the IT system (**R14**): * Full company name incl. legal form * VAT ID if available @@ -75,7 +79,7 @@ If a supplier is not in the IT system the supplier must be added. The following 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**) +The IT system is performing a credit score check, a sanction check and a VAT ID check (if available) in the background (**R15**). If these fail the purchasing department is automatically informed to check the supplier and make changes or the head of purchase may manually approve the new supplier (**R16**). Only after the approval of the supplier orders can be created for that supplier in the IT system. ### Regular supplier checks diff --git a/Processes/02_Purchase_Risk Control Matrix.md b/Processes/02_Purchase_Risk Control Matrix.md index e0131ba..a6e1b0e 100644 --- a/Processes/02_Purchase_Risk Control Matrix.md +++ b/Processes/02_Purchase_Risk Control Matrix.md @@ -1,11 +1,41 @@ # Purchase Risk Control Matrix -| No. | R | Category | Risk Event | L | C | O | Mitigation Type | Mitigation Strategy | L* | C* | Changes | Comments | ES | EY | -| ---- | --------------------------- | --------------------------- | ------------------------------------------------------------ | ---- | ---- | ---------------- | ---------------------------- | ------------------------------------------------------------ | ---- | ---- | ------- | -------- | ---- | ---- | -| 1 | Employee | Operational Risk (Purchase) | Purchasing not the optimal product due to no market research. *"Optimal" includes product/service quality, vendor reliability, price, ...* | 1 | 1 | Many times a day | Preventing (Manual) | Compare products and vendors | 1 | 1 | | | yes | yes | -| 2 | See purchase approval table | Operational Risk (Purchase) | Unauthorized purchase (budget risks, fraud, compliance, ...) | 1 | 1 | Many times a day | Preventing (Manual) | Authorize purchases according to the purchase approval table. This functions as control and separation of responsibilities. | 1 | 1 | | | yes | yes | -| 3 | Purchase + Employee | Operational Risk (Purchase) | Invalid invoice contents (formal or other mistakes) | 1 | 1 | Many times a day | Preventing (Manual & System) | Automatic system checks and manual checks. | 1 | 1 | | | yes | yes | +| No. | R | Category | Risk Event | L | C | O | Cause | Mitigation Type | Mitigation Strategy | L* | C* | Changes | Comments | ES | EY | +| ---- | -------------------------------------- | --------------------------- | ------------------------------------------------------------ | ---- | ---- | ---------------- | ----- | ---------------------------- | ------------------------------------------------------------ | ---- | ---- | ------- | -------- | ---- | ---- | +| 1 | Employee | Operational Risk (Purchase) | Purchasing not the optimal investment product due to no market research. *"Optimal" includes product/service quality, vendor reliability, price, ...* | 1 | 1 | Many times a day | | Preventing (Manual) | Compare products and vendors | 1 | 1 | | | yes | yes | +| 2 | See purchase approval table | Operational Risk (Purchase) | Unauthorized purchase (budget risks, fraud, compliance, ...) | 1 | 1 | Many times a day | | Preventing (Manual) | Authorize purchases according to the purchase approval table. This functions as control and separation of responsibilities. | 1 | 1 | | | yes | yes | +| 3 | Employee | Operational Risk (Purchase) | Critical information related to a purchase are not stored or difficult to find. | 1 | 1 | Many times a day | | Preventing (Manual & System) | Documents and important information related to a purchase are stored in the IT system referring the purchase. | 1 | 1 | | | yes | yes | +| 4 | Purchase | Operational Risk (Purchase) | Invalid invoice contents (formal and other mistakes/deviations) | 1 | 1 | Many times a day | | Preventing (System) | Automatic IT system checks. | 1 | 1 | | | yes | yes | +| 5 | Purchase | Operational Risk (Purchase) | Invalid invoice contents (formal and other mistakes/deviations) | 1 | 1 | Many times a day | | Preventing (Manual) | Additional manual invoice approval by purchase clerk. | 1 | 1 | | | yes | yes | +| 6 | Head of department + Head of purchase | Operational Risk (Purchase) | Deviations between order and invoice | 1 | 1 | Many times a day | | Preventing (Manual) | Approval by responsible staff. | 1 | 1 | | | yes | yes | +| 7 | Finance | Operational Risk (Finance) | Invalid posting. | 1 | 1 | Many times a day | | Preventing (System) | The IT system generates an automatic posting suggestion. | 1 | 1 | | | yes | yes | +| 8 | Finance | Operational Risk (Purchase) | Invalid posting suggestion. | 1 | 1 | Many times a day | | Preventing (Manual) | The accountant can adjust the posting suggestion from the IT system. | 1 | 1 | | | yes | yes | +| 9 | Head of finance | Operational Risk (Purchase) | Invalid posting. | 1 | 1 | Many times a day | | Preventing (System & Manual) | The head of finance checks a selection invoice postings randomly. | 1 | 1 | | | yes | yes | +| 10 | Finance | Operational Risk (Purchase) | Missing invoice payments. | 1 | 1 | Weekly | | Preventing (System) | The IT system generates a list of invoices for payment. | 1 | 1 | | | yes | yes | +| 11 | Finance | Operational Risk (Purchase) | Invalid cash back or forex calculations. | 1 | 1 | Weekly | | Preventing (System) | The IT system automatically calculates the cash back or forex differences. | 1 | 1 | | | yes | yes | +| 12 | Finance | Operational Risk (Purchase) | Invalid payment suggestion. | 1 | 1 | Weekly | | Preventing (Manual) | The accountant can add or remove payments. | 1 | 1 | | | yes | yes | +| 13 | Finance + Head of finance | Operational Risk (Purchase) | Invalid payments | 1 | 1 | Weekly | | Preventing (System & Manual) | Both accountant and head of finance approve the payments. The payment list shows which invoices got manually added, excluded and adjusted. | 1 | 1 | | | yes | yes | +| 14 | Purchase | Operational Risk (Purchase) | Missing supplier information (e.g. important tax information) | 1 | 1 | Many times a day | | Preventing (System) | The IT system requires mandatory information before invoices can be created for a supplier. | 1 | 1 | | | yes | yes | +| 15 | Purchase | Operational Risk (Purchase) | Invalid supplier information | 1 | 1 | Many times a day | | Preventing (System) | The IT system performs automatic checks. | 1 | 1 | | | yes | yes | +| 16 | Head of purchase | Operational Risk (Purchase) | False positive supplier errors. | 1 | 1 | Many times a day | | Preventing (Manual) | Manual supplier approval by head of purchase | 1 | 1 | | | yes | yes | +| 17 | Purchase | Operational Risk (Purchase) | Critical changes to suppliers (e.g. sanctions) | 1 | 1 | Daily | | Preventing (System) | The IT system automatically checks suppliers against sanction lists every day. | 1 | 1 | | | yes | yes | +## Abbreviations +* R: Responsible + +* L: Likelihood (1-5) + +* C: Consequence (1-5) + +* L\*/C\*: Likelihood and Consequence after mitigation + +* O: Occurrence (many times a day, daily, weekly, monthly, annually) + +* ES: Effective + +* EY: Efficient + + 2022-01-01 - Version 1.0 diff --git a/Processes/03_Sales.md b/Processes/03_Sales.md index 8bc6a41..3ac4b08 100644 --- a/Processes/03_Sales.md +++ b/Processes/03_Sales.md @@ -2,6 +2,11 @@ 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 ????. +| Key Objective | Target | Achieved | +| --------------------------- | ------------------ | -------- | +| Sales reach budget | >= XXX EUR (+ Y %) | YES | +| Customer count reach budget | >= XXX | YES | + ## 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 (**R1**): @@ -16,34 +21,36 @@ When making offers to customers the following aspects should always be included * Maintenance contracts are invoiced for 12 months in advance * Offers must be always non-binding -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. +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 (**R2**). If no applicable default offer is available individual offers can be created. -Prices and discounts must follow the pricing policy (**R4**). Deviations from this pricing policy must be approved by the CEO (**R5**). +Prices and discounts must follow the pricing policy and are stored in the IT system (**R3**). Deviations from this pricing policy must be approved by the CEO (**R4**). Changes to the default prices in the IT system can only be done by the head of sales or by the head of finance. (**R5**) Offers can be edited as long as they are not delivered to the customer (or marked as delivered). (**R6**) +All offers created in the IT system are automatically none-binding. (**R7**) + ## 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**): +After receiving the order from the customer the following aspects must be checked manually from the order by the sales department (**R8a**): * 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**) +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. (**R8b**) ## Order confirmation for customer -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**). +Before creating a order confirmation the sales employee has to check if the order from the customer is approved by the head of sales or automatically generated from the IT system (**R8a-R8b**). Afterwards the sales employee can create a order confirmation which must be approved by a sales manager in the IT system. -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**). +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. (**R8a-R8b**). -Order confirmations can be edited as long as they are not delivered to the customer (or marked as delivered). (**R12**). +Order confirmations can be edited as long as they are not delivered to the customer (or marked as delivered). (**R7**). ## Delivery -Invoices can be edited as long as they are not delivered to the customer (or marked as delivered) (**R11**). +Invoices can be edited as long as they are not delivered to the customer (or marked as delivered) (**R7**). ### Manual delivery/setup @@ -63,23 +70,23 @@ Invoices can be manually or automatically printed and send per mail, manually ge ### Invoice contents -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**). +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 (**R4**). -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**) +Taxes on invoices are automatically calculated according to the customer settings and the ordered products and services (**R9**). 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. (**R10**) ### Manual delivery/setup -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**) +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. (**R11**) ### Automatic delivery/setup -In such a case the invoice is automatically and immediately generated by the IT system after the delivery of the order. (**R15**) +In such a case the invoice is automatically and immediately generated by the IT system after the delivery of the order. ## 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**) +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. (**R12**) ### Collection @@ -91,15 +98,17 @@ In case a customer doesn't pay their invoice according to the payment terms they | 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**) +Payment reminders are generated by the IT system every 2 weeks (**R13**). 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. -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**) +After the second reminder, the account gets automatically locked by the IT system and no further orders can be made by the customer. (**R14**) -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**) +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 based on a IT system generated accounts receivable list. (**R15**) + +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. ### 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**). +The IT system automatically tries to match the payments to unpaid accounts receivables and/or customers based on the provided information from the payment (**R16**). The accounts receivable accountant responsible for booking customer payments has to approve or adjust the IT system suggestions (**R17**). #### Credit Card @@ -113,7 +122,7 @@ The IT system automatically tries to match the payments to unpaid accounts recei ### 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**): +If a customer is not in the IT system the customer must be added. The following information must be added to the IT system (**R18**): * Full company name incl. legal form * VAT ID if available @@ -128,11 +137,11 @@ If a customer is not in the IT system the customer must be added. The following 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**). +The IT system is performing a credit score check (**R19a-R19b**), a sanction check and a VAT ID check (if available) in the background (**R19**). If these fail the sales department is automatically informed to check the customer and make changes or manually approve the new customer (**R20**). Only after the approval of the customer offers, order confirmations, invoices, etc. can be created for that customer in the IT system ### Regular customer checks -Once a day every customer is automatically checked against sanction lists. (**R27**) +Once a day every customer is automatically checked against sanction lists. (**R21**) ### Customer acquisition diff --git a/Processes/03_Sales_Risk Control Matrix.md b/Processes/03_Sales_Risk Control Matrix.md index ab8ac93..f383432 100644 --- a/Processes/03_Sales_Risk Control Matrix.md +++ b/Processes/03_Sales_Risk Control Matrix.md @@ -1,13 +1,48 @@ # Sales Risk Control Matrix -| No. | R | Category | Risk Event | L | C | O | Mitigation Type | 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 | Preventing (System & Manual) | 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. | 1 | 1 | | | yes | yes | -| 2 | Head of Sales | Operational Risk (Sales) | Default prices are too low / default discounts are too large | 1 | 5 | Many times a day | Preventing (System & Manual) | Changes to default prices and default discounts can only be entered into the IT system by the head of sales or head of finance. | 1 | 1 | | | yes | yes | -| 3 | Head of Sales | Operational Risk (Sales) | Other aspects of the offer are invalid (i.e. wrong customer, bad credit score of customer, ...) | 1 | 5 | Many times a day | Preventing (System) | The offer is none-binding and only becomes binding with the order confirmation where additional checks are performed. | 1 | 1 | | | yes | yes | -| 4 | Head of Sales | Operational Risk (Sales) | Invalid customer data | 1 | 5 | | Preventing (System) | Customer data gets compared with the information provided from credit rating agencies, company registration forms etc. | 1 | 1 | | | yes | yes | -| 5 | Head of Sales | Operational Risk (Sales) | Customer default | 1 | 5 | | Preventing (System) | Only customers with a credit score of XXXX-Crefo / XXXX-Coface / XXXX-Schufa get approved during the order confirmation. | 1 | 1 | | | yes | yes | +| No. | R | Category | Risk Event | L | C | O | Cause | Mitigation Type | Mitigation Strategy | L* | C* | Changes | Comments | ES | EY | +| ---- | ------------------------------- | --------------------------- | ------------------------------------------------------------ | ---- | ---- | ---------------- | ----- | ---------------------------- | ------------------------------------------------------------ | ---- | ---- | ------- | ------------------------------------------------------------ | ---- | ---- | +| 1 | Sales | Operational Risk (Sales) | Invalid offer | 1 | 1 | Many times a day | | Preventing (System) | Use default offers. | 1 | 1 | | | yes | yes | +| 2 | Sales | Operational Risk (Sales) | No flexibility in case of none-standard customer requests. | 1 | 1 | Many times a day | | Preventing (Manual) | Custom offers for customers. | 1 | 1 | | | yes | yes | +| 3 | Head of Sales / Head of Finance | Operational Risk (Sales) | Prices too low / discounts too large | 1 | 5 | Many times a day | | Preventing (System & Manual) | Default prices and standard discounts are stored in the IT system responsible for the offer generation. | 1 | 1 | | | yes | yes | +| 4 | CEO | Operational Risk (Sales) | Prices too low / discounts too large | 1 | 5 | Many times a day | | Preventing (System & Manual) | Deviations from the pricing policy require additional electronic approval in the system by the head of sales or head of finance. Without this electronic approval the offer cannot get created. | 1 | 1 | | | yes | yes | +| 5 | Head of Sales / Head of finance | Operational Risk (Sales) | Default prices are too low / default discounts are too large | 1 | 5 | Many times a day | | Preventing (System & Manual) | Changes to default prices and default discounts can only be entered into the IT system by the head of sales or head of finance. | 1 | 1 | | | yes | yes | +| 6 | Sales | Operational Risk (Sales) | Changes to offers, order confirmations, offers etc. | 1 | 1 | Many times a day | | Preventing (System) | Changes are only possible as long as they are not marked as delivered in the IT system. | 1 | 1 | | | yes | yes | +| 7 | Sales | Operational Risk (Sales) | Other aspects of the offer are invalid (i.e. wrong customer, bad credit score of customer, ...) | 1 | 5 | Many times a day | | Preventing (System) | The offer is none-binding and only becomes binding with the order confirmation where additional checks are performed. | 1 | 1 | | | yes | yes | +| 8a | Sales | Operational Risk (Sales) | Invalid order from customer (e.g. changes to the offer) | 1 | 1 | Many times a day | | Preventing (Manual) | The order from the customer must be checked by a sales clerk. | 1 | 1 | | | yes | yes | +| 8b | Sales | Operational Risk (Sales) | Invalid order from customer (e.g. changes to the offer) | 1 | 1 | Many times a day | | Preventing (System) | Online orders from the shop are automatically generated by the IT system according to the allowed prices and products etc. | 1 | 1 | | | yes | yes | +| 9 | Sales | Operational Risk (Sales) | Invalid tax calculation | 1 | 1 | Many times a day | | Preventing (System) | The IT system automatically calculates the taxes based on the item and customer settings. | 1 | 1 | | | yes | yes | +| 10 | Sales | Operational Risk (Sales) | Invalid automatic tax calculation | 1 | 1 | Many times a day | | Preventing (Manual) | An accountant can adjust the taxes if necessary. | 1 | 1 | | *This can be necessary for special cases such as chain transactions.* | yes | yes | +| 11 | Head of sales | Operational Risk (Sales) | Changes between order confirmation and invoice. | 1 | 1 | Many times a day | | Preventing (System & Manual) | Changes between order confirmation and invoice must be approved by the head of sales before the invoice can get created. | 1 | 1 | | | yes | yes | +| 12 | Accounting | Operational Risk (Finance) | Invalid posting. | 1 | 1 | Many times a day | | Preventing (System) | The IT system automatically generates the posting for invoices based on item and customer settings. | 1 | 1 | | | yes | yes | +| 13 | Accounting | Operational Risk (Finance) | Unpaid invoice. | 1 | 1 | Every 2 Weeks | | Revealing (System) | The IT system automatically generates reminders every 2 weeks. | 1 | 1 | | | yes | yes | +| 14 | Accounting | Operational Risk (Finance) | Customer continues to receive products despite not paying invoices. | 1 | 1 | Every 2 Weeks | | Preventing (System) | The IT system automatically locks the customer account preventing further customer orders. | 1 | 1 | | | yes | yes | +| 15 | Accounting | Operational Risk (Finance) | Customers don't pay after reminder. | 1 | 1 | Every 2 Weeks | | Revealing (Manual) | Invoices can get handed over to a lawyer for collection based on the decision of the head of finance. | 1 | 1 | | | yes | yes | +| 16 | Accounting | Operational Risk (Finance) | Invalid payment matching. | 1 | 1 | Many times a day | | Preventing (System) | The IT system generates suggestions for matching payments with customers/invoices. | 1 | 1 | | | yes | yes | +| 17 | Accounting | Operational Risk (Finance) | Invalid payment suggestion matching. | 1 | 1 | Many times a day | | Preventing (Manual) | The account can manually adjust the payment matching. | 1 | 1 | | | yes | yes | +| 18 | Sales | Operational Risk (Purchase) | Missing customer information (e.g. important tax information) | 1 | 1 | Many times a day | | Preventing (System) | The IT system requires mandatory information before invoices and order confirmations can be created for a customer. | 1 | 1 | | | yes | yes | +| 19 | Sales | Operational Risk (Purchase) | Invalid customer information | 1 | 1 | Many times a day | | Preventing (System) | The IT system performs automatic checks. | 1 | 1 | | | yes | yes | +| 19a | Sales | Operational Risk (Sales) | Invalid customer data | 1 | 5 | Many times a day | | Preventing (System) | Customer data gets compared with the information provided from credit rating agencies, company registration forms etc. | 1 | 1 | | | yes | yes | +| 19b | Sales | Operational Risk (Sales) | Customer default | 1 | 5 | Many times a day | | Preventing (System) | Only customers with a credit score of XXXX-Crefo / XXXX-Coface / XXXX-Schufa get approved during the order confirmation. | 1 | 1 | | | yes | yes | +| 20 | Head of sales | Operational Risk (Purchase) | False positive customer errors. | 1 | 1 | Many times a day | | Preventing (Manual) | Manual customer approval by head of sales | 1 | 1 | | | yes | yes | +| 21 | Sales | Operational Risk (Purchase) | Critical changes to customer (e.g. sanctions) | 1 | 1 | Daily | | Preventing (System) | The IT system automatically checks customers against sanction lists every day. | 1 | 1 | | | yes | yes | +## Abbreviations +* R: Responsible + +* L: Likelihood (1-5) + +* C: Consequence (1-5) + +* L\*/C\*: Likelihood and Consequence after mitigation + +* O: Occurrence (many times a day, daily, weekly, monthly, annually) + +* ES: Effective + +* EY: Efficient + + 2022-01-01 - Version 1.0 diff --git a/Processes/04_Support & Service.md b/Processes/04_Support & Service.md index 2ac1f46..d5a0884 100644 --- a/Processes/04_Support & Service.md +++ b/Processes/04_Support & Service.md @@ -1,6 +1,10 @@ # 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. +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. + +| Key Objective | Target | Achieved | +| --------------------------- | ------ | -------- | +| Great customer satisfaction | >= 4.0 | YES | ## Data migration @@ -10,7 +14,9 @@ Only after the binding approval by the customer the order confirmation will be c ## Setup & configuration -### Virtual environment +### Environment + +The software envi ### Software installation and configuration on virtual environment diff --git a/Processes/04_Support & Service_Risk Control Matrix.md b/Processes/04_Support & Service_Risk Control Matrix.md index f4a3291..acd2fb1 100644 --- a/Processes/04_Support & Service_Risk Control Matrix.md +++ b/Processes/04_Support & Service_Risk Control Matrix.md @@ -1,6 +1,25 @@ # Support & Service Risk Control Matrix +| No. | R | Category | Risk Event | L | C | O | Cause | Mitigation Type | Mitigation Strategy | L* | C* | Changes | Comments | ES | EY | +| ---- | ---- | -------- | ---------- | ---- | ---- | ---- | ----- | --------------- | ------------------- | ---- | ---- | ------- | -------- | ---- | ---- | +| 1 | | | | | | | | | | | | | | | | +## Abbreviations + +* R: Responsible + +* L: Likelihood (1-5) + +* C: Consequence (1-5) + +* L\*/C\*: Likelihood and Consequence after mitigation + +* O: Occurrence (many times a day, daily, weekly, monthly, annually) + +* ES: Effective + +* EY: Efficient + + 2022-01-01 - Version 1.0 - diff --git a/Processes/05_HR.md b/Processes/05_HR.md index b020b38..39e36e6 100644 --- a/Processes/05_HR.md +++ b/Processes/05_HR.md @@ -1,17 +1,21 @@ # HR +| Key Objective | 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 | +| 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 | +| 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 | + ## Hiring -| 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 | - ### Search -#### Approval +#### Identify & 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**): +Before searching for a new employee the current HR situation must be evaluated and the need for a hiring must be identified. The identification can happen during the budgeting process, regular department meetings, executive meetings or even during the ongoing business operations. 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 @@ -97,29 +101,29 @@ The result of the voting process is logged in the notes of the HR employee and m ### 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 employment contract must be created by the HR department. The basis for the contract is the [Sample Contract](./HR/Hiring/Sample%20Contract.md) (**R14**), 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 (**R15**). 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**). +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 (**R16**). -- [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**) +- [x] The applicant in the contract got selected by the selection committee (**R16a**) +- [x] Application contains credentials (**R16b**) +- [x] Credentials are verified (**R16c**) +- [x] Contract is signed by applicant +- [x] The signed contract is the approved version (unaltered) (**R16d**) +- [x] NDA is signed (**R16e**) +- [x] CLA is signed (**R16f**) +- [x] Privicy policy is signed (**R16g**) +- [x] Criminal record certificate (**R16h**) and no sanctions which prevent hiring (**R16i**) +- [x] Applicant tax id is available (**R16j**) +- [x] Work permit is available (if necessary) (**R16k**) -The employment contract must only get signed by an authorized persons in the organization (e.g. CEO, executive staff member, authorized officers). (**R16**) +The employment contract must only get signed by an authorized persons in the organization (e.g. CEO, executive staff member, authorized officers). (**R17**) ### 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**) +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. (**R18**) -This training plan must get signed by the employee after completion in order to document the successful training. (**R18**) +This training plan must get signed by the employee after completion in order to document the successful training. (**R19**) ### Employee file @@ -142,37 +146,27 @@ Documents from the hiring process attached in the employee file are: ## 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 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 (**R20**). 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 (**R21**). -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**) +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. (**R22**) ### 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. +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 (**R23**). 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**) +Every year every employee receives a Company Evaluation Form which they can fill out and anonymously submit to the HR department (**R24**). These forms are evaluated and analyzed by the HR department to find improvements for the company. (**R25**) ### Regularly employee checks -Every employee is checked automatically every night against sanctions lists in the IT system (**R50**) +Every employee is checked automatically every night against sanctions lists in the IT system (**R26**) diff --git a/Processes/05_HR_Flowchart.md b/Processes/05_HR_Flowchart.md index e69de29..6bc545b 100644 --- a/Processes/05_HR_Flowchart.md +++ b/Processes/05_HR_Flowchart.md @@ -0,0 +1,34 @@ +# HR Flowchart + +## Hiring + +```mermaid +graph TD; + IDENTIFY([Identify need for new position])-->APPROVAL[Position Approval]; + APPROVAL-->APPROVAL_SEARCH{Is approved?}; + APPROVAL_SEARCH--YES-->SEARCH[Search]; + SEARCH-->CHECK_APPLICATION{Application fits?}; + CHECK_APPLICATION--YES-->SKIP_FIRST{Is manager?}; + SKIP_FIRST--YES-->INTERVIEW_1[First interview]; + SKIP_FIRST--NO-->INTERVIEW_2; + CHECK_APPLICATION--NO-->REJECT[Reject application]; + INTERVIEW_1-->CHECK_INTERVIEW_1{Interview was good?}; + CHECK_INTERVIEW_1--YES-->INTERVIEW_2[Second interview]; + CHECK_INTERVIEW_1--NO-->REJECT; + INTERVIEW_2-->CHECK_INTERVIEW_2{Interview was good?}; + CHECK_INTERVIEW_2--YES-->CHECK_REFERENCES{Valid references?}; + CHECK_REFERENCES--YES-->INTERVIEW_3[Third interview]; + CHECK_REFERENCES--NO-->REJECT; + CHECK_INTERVIEW_2--NO-->REJECT; + INTERVIEW_3-->CHECK_INTERVIEW_3{Interview was good?}; + CHECK_INTERVIEW_3--NO-->REJECT; + CHECK_INTERVIEW_3--YES-->VOTE{Vote hiring?} + VOTE--YES-->SIGN_CONTRACT[Sign contract]; + VOTE--NO-->REJECT + SIGN_CONTRACT-->TRAIN([Train employee]) +``` + + + +2022-01-01 - Version 1.0 + diff --git a/Processes/05_HR_Risk Control Matrix.md b/Processes/05_HR_Risk Control Matrix.md index e69de29..3e77f86 100644 --- a/Processes/05_HR_Risk Control Matrix.md +++ b/Processes/05_HR_Risk Control Matrix.md @@ -0,0 +1,50 @@ +# HR Risk Control Matrix + +| No. | R | Category | Risk Event | L | C | O | Cause | Mitigation Type | Mitigation Strategy | L* | C* | Changes | Comments | ES | EY | +| ---- | ---- | -------- | ---------- | ---- | ---- | ---- | ----- | --------------- | ------------------- | ---- | ---- | ------- | -------- | ---- | ---- | +| 1 | | | | | | | | | | | | | | | | +| 2 | | | | | | | | | | | | | | | | +| 3 | | | | | | | | | | | | | | | | +| 4 | | | | | | | | | | | | | | | | +| 5 | | | | | | | | | | | | | | | | +| 6 | | | | | | | | | | | | | | | | +| 7 | | | | | | | | | | | | | | | | +| 8 | | | | | | | | | | | | | | | | +| 9 | | | | | | | | | | | | | | | | +| 10 | | | | | | | | | | | | | | | | +| 11 | | | | | | | | | | | | | | | | +| 12 | | | | | | | | | | | | | | | | +| 13 | | | | | | | | | | | | | | | | +| 14 | | | | | | | | | | | | | | | | +| 15 | | | | | | | | | | | | | | | | +| 16 | | | | | | | | | | | | | | | | +| 17 | | | | | | | | | | | | | | | | +| 18 | | | | | | | | | | | | | | | | +| 19 | | | | | | | | | | | | | | | | +| 20 | | | | | | | | | | | | | | | | +| 21 | | | | | | | | | | | | | | | | +| 22 | | | | | | | | | | | | | | | | +| 23 | | | | | | | | | | | | | | | | +| 24 | | | | | | | | | | | | | | | | +| 25 | | | | | | | | | | | | | | | | +| 26 | | | | | | | | | | | | | | | | + +## Abbreviations + +* R: Responsible + +* L: Likelihood (1-5) + +* C: Consequence (1-5) + +* L\*/C\*: Likelihood and Consequence after mitigation + +* O: Occurrence (many times a day, daily, weekly, monthly, annually) + +* ES: Effective + +* EY: Efficient + + + +2022-01-01 - Version 1.0 diff --git a/Processes/06_Finance.md b/Processes/06_Finance.md index e0e3e14..44ad140 100644 --- a/Processes/06_Finance.md +++ b/Processes/06_Finance.md @@ -1,22 +1,27 @@ # Finance +| Key Objective | Target | Achieved | +| ------------------------- | ------------------- | -------- | +| Create annual budget | Get budget approved | YES | +| Correct financial figures | Pass annual audit | YES | + ## Budgeting -The budgeting for the organization is done once a year and involves the cooperation of various departments to create a comprehensive budget with a solid basis for the included assumptions. +The budgeting for the organization is done once a year and involves the cooperation of various departments to create a comprehensive budget with a solid basis for the included assumptions. (**R1**) ### Approval #### Deadline -The deadline for the handover of the budget by the finance department to the management is December 15th. +The deadline for the handover of the budget by the finance department to the management is December 15th. (**R2**) #### Responsibilities -The approval of the budget is handled by the management and should be done until the start of the next fiscal year. +The approval of the budget is handled by the management and should be done until the start of the next fiscal year. (**R3**) -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. +If amendments need to be made the management may approve a preliminary budget until the actual budget is finalized and approved (**R4**). 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. +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. (**R5a**) (**R5b**) ### Forecast @@ -24,7 +29,7 @@ The basis of many figures and KPIs for the budgeted periods is the current fisca ### Contents -The budget must be created on a monthly basis. During the budgeting process it may be helpful to only budget the full fiscal year and then split the total budget up into 12 months. While doing so variations in different months should be considered (e.g. audit fees in specific months, seasonal sales distribution, ...). +The budget must be created on a monthly basis (**R6**). During the budgeting process it may be helpful to only budget the full fiscal year and then split the total budget up into 12 months. While doing so variations in different months should be considered (e.g. audit fees in specific months, seasonal sales distribution, ...). #### Sales @@ -48,7 +53,7 @@ Operating expenses must contain the following information: ##### Information requested from all departments -The following budget positions must be budgeted from the respective head of the department: +The following budget positions must be budgeted from the respective head of the department (**R7**): * Employee trainings * Investments @@ -92,31 +97,31 @@ The taxes should be estimated based on the EBIT and the local tax rate. Correcti ### Deadline -The deadline is the 4th work day of the following month. +The deadline is the 4th work day of the following month. (**R8**) ### 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. +The tasks and responsibilities can be found in the [Monthly Closing Checklist](Finance/Financial%20Closing/Monthly%Closing%20Checklist.md). The checklist must be signed by every responsible person after completing the defined task. (**R9**) ## Annual closing ### Deadline -The deadline is the 4th work day of the new fiscal year. +The deadline is the 4th work day of the new fiscal year. (**R10**) ### 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. +The tasks and responsibilities can be found in the [Monthly Closing Checklist](Finance/Financial%20Closing/Monthly%Closing%20Checklist.md) and additionally the [Annual Closing Checklist](Finance/Financial%20Closing/Annual%Closing%20Checklist.md). The checklists must be signed by every responsible person after completing the defined task. (**R11**) ## Annual financial audit ### Deadline -The deadline for the audit preparation is 3 days before the audit takes place. +The deadline for the audit preparation is 3 days before the audit takes place. (**R12**) ### 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. +The tasks and responsibilities can be found in the [Annual Audit Checklist](Finance/Financial%20Closing/Annual%20Audit%20Checklist.md). The checklist must be signed by every responsible person after completing the defined task. (**R13**) ## Reporting @@ -124,13 +129,11 @@ The reporting for the organization is done once a month and shared with differen ### Deadline -The deadline is the 5th work day of the following month. +The deadline is the 5th work day of the following month. (**R14**) ### 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 +The tasks and responsibilities can be found in the [Monthly Reporting Checklist](Finance/Reporting/Monthly%20Reporting%20Checklist.md). The checklist must be signed by every responsible person after completing the defined task. (**R15a**) (**R15b**) diff --git a/Processes/06_Finance_Risk Control Matrix.md b/Processes/06_Finance_Risk Control Matrix.md index e69de29..2da30b8 100644 --- a/Processes/06_Finance_Risk Control Matrix.md +++ b/Processes/06_Finance_Risk Control Matrix.md @@ -0,0 +1,41 @@ +# Finance Risk Control Matrix + +| No. | R | Category | Risk Event | L | C | O | Cause | Mitigation Type | Mitigation Strategy | L* | C* | Changes | Comments | ES | EY | +| ---- | ---- | -------- | ---------- | ---- | ---- | ---- | ----- | --------------- | ------------------- | ---- | ---- | ------- | -------- | ---- | ---- | +| 1 | | | | | | | | | | | | | | | | +| 2 | | | | | | | | | | | | | | | | +| 3 | | | | | | | | | | | | | | | | +| 4 | | | | | | | | | | | | | | | | +| 5a | | | | | | | | | | | | | | | | +| 5b | | | | | | | | | | | | | | | | +| 6 | | | | | | | | | | | | | | | | +| 7 | | | | | | | | | | | | | | | | +| 8 | | | | | | | | | | | | | | | | +| 9 | | | | | | | | | | | | | | | | +| 10 | | | | | | | | | | | | | | | | +| 11 | | | | | | | | | | | | | | | | +| 12 | | | | | | | | | | | | | | | | +| 13 | | | | | | | | | | | | | | | | +| 14 | | | | | | | | | | | | | | | | +| 15a | | | | | | | | | | | | | | | | +| 15b | | | | | | | | | | | | | | | | + +## Abbreviations + +* R: Responsible + +* L: Likelihood (1-5) + +* C: Consequence (1-5) + +* L\*/C\*: Likelihood and Consequence after mitigation + +* O: Occurrence (many times a day, daily, weekly, monthly, annually) + +* ES: Effective + +* EY: Efficient + + + +2022-01-01 - Version 1.0 diff --git a/Processes/07_Management.md b/Processes/07_Management.md index 3dfb1d8..b710472 100644 --- a/Processes/07_Management.md +++ b/Processes/07_Management.md @@ -1,5 +1,9 @@ # Management +| Key Objective | Target | Achieved | +| ------------------- | ---------- | -------- | +| Reach budgeted EBIT | >= XXX EUR | YES | + ## Planning ## Organizing @@ -11,3 +15,4 @@ ## Leading ## Controlling & Optimization + diff --git a/Processes/07_Management_Risk Control Matrix.md b/Processes/07_Management_Risk Control Matrix.md index e69de29..0dec21f 100644 --- a/Processes/07_Management_Risk Control Matrix.md +++ b/Processes/07_Management_Risk Control Matrix.md @@ -0,0 +1,25 @@ +# Management Risk Control Matrix + +| No. | R | Category | Risk Event | L | C | O | Cause | Mitigation Type | Mitigation Strategy | L* | C* | Changes | Comments | ES | EY | +| ---- | ---- | -------- | ---------- | ---- | ---- | ---- | ----- | --------------- | ------------------- | ---- | ---- | ------- | -------- | ---- | ---- | +| 1 | | | | | | | | | | | | | | | | + +## Abbreviations + +* R: Responsible + +* L: Likelihood (1-5) + +* C: Consequence (1-5) + +* L\*/C\*: Likelihood and Consequence after mitigation + +* O: Occurrence (many times a day, daily, weekly, monthly, annually) + +* ES: Effective + +* EY: Efficient + + + +2022-01-01 - Version 1.0 \ No newline at end of file diff --git a/Processes/08_Quality Management b/Processes/08_Quality Management index b3792a2..74b0a5a 100644 --- a/Processes/08_Quality Management +++ b/Processes/08_Quality Management @@ -1,6 +1,8 @@ # Quality Management - +| Key Objective | Target | Achieved | +| ---------------------- | ----------------------------------- | -------- | +| High quality standards | Pass annual quality audit checklist | YES | 2022-01-01 - Version 1.0 diff --git a/Processes/08_Quality Management_Risk Control Matrix.md b/Processes/08_Quality Management_Risk Control Matrix.md index e69de29..5001c9b 100644 --- a/Processes/08_Quality Management_Risk Control Matrix.md +++ b/Processes/08_Quality Management_Risk Control Matrix.md @@ -0,0 +1,25 @@ +# Quality Management Risk Control Matrix + +| No. | R | Category | Risk Event | L | C | O | Cause | Mitigation Type | Mitigation Strategy | L* | C* | Changes | Comments | ES | EY | +| ---- | ---- | -------- | ---------- | ---- | ---- | ---- | ----- | --------------- | ------------------- | ---- | ---- | ------- | -------- | ---- | ---- | +| 1 | | | | | | | | | | | | | | | | + +## Abbreviations + +* R: Responsible + +* L: Likelihood (1-5) + +* C: Consequence (1-5) + +* L\*/C\*: Likelihood and Consequence after mitigation + +* O: Occurrence (many times a day, daily, weekly, monthly, annually) + +* ES: Effective + +* EY: Efficient + + + +2022-01-01 - Version 1.0 \ No newline at end of file diff --git a/Processes/COSO/CLC.md b/Processes/COSO/CLC.md index 96adb56..e798ab2 100644 --- a/Processes/COSO/CLC.md +++ b/Processes/COSO/CLC.md @@ -2,44 +2,43 @@ | No. | Component | Control Area | Question | Answer | Evidence | | ---- | ----------------------------- | ------------------------------------- | ------------------------------------------------------------ | ------------------------------------------------------------ | ------------------------------------------------------------ | -| | Control Environment | Principle of financial reporting | Do you have basic financial reporting policies? | Yes, the organization follows the German law regarding financial reporting | Financial laws (i.e. HGB, AO, Ustg, ...) | -| | Control Environment | Understanding accounting policies | Are the selected accounting principles approved? | Yes, employees are required to act according to the the German law | Financial laws (i.e. HGB, AO, Ustg, ...) | -| | Control Environment | Management philosophy and application | Does management determine the management philosophy, operating style and code of ethics and manifest them to employees? | Yes, all are described in the organization guidelines | [Code of Conduct](../../Policies%20%26%20Guidelines/Code%20of%20Conduct.md)
Organization Guidelines
Conflict of Interest Policy
Confidentiality Policy | -| | Control Environment | Management philosophy and application | Do you have any procedures or processes to remediate detected behaviors deviating from the management philosophy, operating style and code of ethics | Yes, public email to submit deviating behavior, public discussion and issue tracker to bring forward deviating behavior | [Code of Conduct](../../Policies%20%26%20Guidelines/Code%20of%20Conduct.md)
[Discussions](https://github.com/orgs/Karaka-Management/discussions)
[Issues](https://github.com/Karaka-Management/Karaka/issues) | -| | Control Environment | Management philosophy and application | In case you find deviations from the principles, do you deal with them according to the predetermined procedures or processes? | Yes, so far no such case ocured | Code of Conduct
Organization Guidelines
Conflict of Interest Policy
Confidentiality Policy | -| | Control Environment | Director | Do you have any company rules to clearly specify that the board of directors or a director in charge have responsibilities for appropriately supervising and monitoring the management in regard to the financial reporting and relevant internal controls? | No, apart from the legal obligations | | -| | Control Environment | Director | Does the board of directors or corporate auditors supervise the performance of management regard the financial reporting and relevant internal controls? | Yes, financial controls are audited by independent auditors | Annual year end audit | -| | Control Environment | Organization | Does the management appropriately improve organizational structures or practices to resolve existing problems considering the size, content of the operations and business objectives of the company? | | | -| | Control Environment | Organization | Does the management assign roles in regard to each function and activity unit in the company? | | | -| | Control Environment | Organization | Do you have any rules to clarify segregation of duties and appropriately delegate authority and responsibilities to personnel in charge of each function and activity unit in the company? | | | -| | Control Environment | Organization | Does the management assign a person in charge for each role? | | | -| | Control Environment | Power | Are the assignment of responsibilities and delegation of authority made clear to all employees? | | | -| | Control Environment | Power | Is the delegation of responsibilities and authority to employees, etc. kept at appropriate levels, not without limitation? | | | -| | Control Environment | Power | Are the delegation of responsibilities and authority to employees, etc. updated on a timely basis in case organizational structures or other fundamentals of the company are changed? | | | -| | Control Activities | Business procedure | Are policies and procedures or operating manuals established to ensure the performance of control activities that sufficiently mitigate and address the risks in business operations, especially in regard to the reliability of the financial reporting? | | | -| | Control Activities | Business procedure | How do you confirm if employees perform their operations in compliance with policies and procedures or operating manuals? | | | -| | Control Environment | Personnel deployment and training | Does the management identify the competencies necessary for the company and procure/dispatch qualified personnel | | | -| | Control Environment | Personnel deployment and training | Are the competencies necessary reviewed regularly and maintained appropriately? | | | -| | Control Environment | Personnel deployment and training | Does the management provide employees, etc. with the means, training etc. necessary to fulfill their duties and support them in the improvement of their abilities? | | | -| | Control Environment | Personnel evaluation | Do you have personnel evaluation standards? | | | -| | Control Environment | Personnel evaluation | Are the personnel evaluation standards regularly reviewed and updated appropriately? | | | -| | Risk Assessment and Response | Risk assessment structure | Is there an effective risk assessment system that involves appropriate levels of the management and managers? | | | -| | Risk Assessment and Response | Risk assessment structure | Does the management asses the risk considering not only superficial facts but also backgrounds, incidents and other substantial elements? | | | -| | Risk Assessment and Response | Risk assessment structure | Does the management appropriately assess and address fraud risks based on not only superficial facts regarding fraud, but also incentives, causes, backgrounds and other factors that may result in fraud? | | | -| | Risk Assessment and Response | Risk assessment structure | Does the management reassess the risk and take appropriate measures whenever changes occur that may have a significant impact on the company? | | | -| | Communication and information | Communicating information | Are the management's or supervisor's instruction communicated to all employees? | | | -| | Communication and information | Communicating information | Is a system set in place to ensure that external information on internal controls is properly utilized and adequately communicated to the management or internal audit section? | | | -| | Communication and information | Internal reporting | Do you have the Whistleblower System or other internal reporting program? | | | -| | Communication and information | Internal reporting | Is the system or program in operation according to its original design? | | | -| | Communication and information | Financial information | How does the management acquire or access the accounting and financial information of the company? | | | -| | Communication and information | Financial information | How are the accounting and financial information or data from relevant business processes input to your accounting system or application? | | | -| | Communication and information | Information sharing with managements | Do you have any internal rules documents which stipulate that the managements should share business an other information with each other | | | -| | Communication and information | Information sharing with managements | Does your management share information with each other in actual business? | | | -| | Monitoring | Ongoing monitoring | Are ongoing monitoring activities appropriately embedded within the company's overall business operations? | | | -| | Monitoring | Ongoing monitoring | Are the ongoing monitoring activities operated appropriately according to the original designs and purposes? | | | -| | Monitoring | Independent monitoring | Do you have any independent monitoring system other than ongoing monitoring activities embedded within the company's business operations, such as internal audits? | | | -| | Monitoring | Independent monitoring | Are the ongoing monitoring activities operated appropriately according to the original designs and purposes | | | -| | Monitoring | Response to results of monitoring | Are errors, material weakness of internal controls, etc. detected through the performance of control activities or noticed from outside the company timely reported to the management or senior managers and appropriately investigated and properly addressed? | | | +| 1 | Control Environment | Principle of financial reporting | Do you have basic financial reporting policies? | Yes, the organization follows the German law regarding financial reporting and internal reporting guidelines. | Financial laws (i.e. HGB, AO, Ustg, ...)
Policies: Reporting
Process: Finance | +| 2 | Control Environment | Understanding accounting policies | Are the selected accounting principles approved? | Yes, employees are required to act according to the the German law and follow the accounting policies. | Financial laws (i.e. HGB, AO, Ustg, ...)
Policies: Accounting | +| 3 | Control Environment | Management philosophy and application | Does management determine the management philosophy, operating style and code of ethics and manifest them to employees? | Yes, all are described in the organization guidelines | [Code of Conduct](../../Policies%20%26%20Guidelines/Code%20of%20Conduct.md)
Organization Guidelines
Conflict of Interest Policy
Confidentiality Policy | +| 4 | Control Environment | Management philosophy and application | Do you have any procedures or processes to re-mediate detected behaviors deviating from the management philosophy, operating style and code of ethics | Yes, public email to submit deviating behavior, public discussion and issue tracker to bring forward deviating behavior | [Code of Conduct](../../Policies%20%26%20Guidelines/Code%20of%20Conduct.md)
[Discussions](https://github.com/orgs/Karaka-Management/discussions)
[Issues](https://github.com/Karaka-Management/Karaka/issues) | +| 5 | Control Environment | Management philosophy and application | In case you find deviations from the principles, do you deal with them according to the predetermined procedures or processes? | Yes, so far no such case occurred | Code of Conduct
Organization Guidelines
Conflict of Interest Policy
Confidentiality Policy | +| 6 | Control Environment | Director | Do you have any company rules to clearly specify that the board of directors or a director in charge have responsibilities for appropriately supervising and monitoring the management in regard to the financial reporting and relevant internal controls? | Yes, legal obligations and the finance process must be followed. | Process: Finance | +| 7 | Control Environment | Director | Does the board of directors or corporate auditors supervise the performance of management regard the financial reporting and relevant internal controls? | Yes, financial controls are audited by independent auditors | Annual year end audit | +| 8 | Control Environment | Organization | Does the management appropriately improve organizational structures or practices to resolve existing problems considering the size, content of the operations and business objectives of the company? | Yes, during the budget process and if necessary based on information provided during meetings such as the executive committee meeting. | Budget
Executive Committee Meeting Minutes | +| 9 | Control Environment | Organization | Does the management assign roles in regard to each function and activity unit in the company? | Yes. This can be seen in the organigram. | Organigram
Processes
Checklists | +| 10 | Control Environment | Organization | Do you have any rules to clarify segregation of duties and appropriately delegate authority and responsibilities to personnel in charge of each function and activity unit in the company? | Yes. This can be seen in the organigram and in the processes. | Organigram
Processes
Checklists | +| 11 | Control Environment | Organization | Does the management assign a person in charge for each role? | Yes. This can be seen in the organigram. | Organigram
Processes
Checklists | +| 12 | Control Environment | Power | Are the assignment of responsibilities and delegation of authority made clear to all employees? | Yes. This can be seen in the organigram and processes. | Organigram
Processes
Checklists | +| 13 | Control Environment | Power | Is the delegation of responsibilities and authority to employees, etc. kept at appropriate levels, not without limitation? | Yes. This can be seen in the organigram and processes. | Organigram
Processes
Checklists | +| 14 | Control Environment | Power | Are the delegation of responsibilities and authority to employees, etc. updated on a timely basis in case organizational structures or other fundamentals of the company are changed? | Yes. This can be seen in the organigram and processes. | Organigram
Processes
Checklists | +| 15 | Control Activities | Business procedure | Are policies and procedures or operating manuals established to ensure the performance of control activities that sufficiently mitigate and address the risks in business operations, especially in regard to the reliability of the financial reporting? | Yes. This is done in the risk control matrix of every process, risk management, CLC and ITGC. | Process Risk Control Matrix
Risk Management
Risk Review
CLC
ITGC | +| 16 | Control Activities | Business procedure | How do you confirm if employees perform their operations in compliance with policies and procedures or operating manuals? | This is done through the implemented controls and annual risk review. | Process Risk Control Matrix
Risk Review | +| 17 | Control Environment | Personnel deployment and training | Does the management identify the competencies necessary for the company and procure/dispatch qualified personnel | Yes, this is done during the HR search and the employee evaluation. | Job description
Employee Evaluation Form | +| 18 | Control Environment | Personnel deployment and training | Are the competencies necessary reviewed regularly and maintained appropriately? | Yes, this is done during the HR search and the annual employee evaluation. | Job description
Employee Evaluation Form | +| 19 | Control Environment | Personnel deployment and training | Does the management provide employees, etc. with the means, training etc. necessary to fulfill their duties and support them in the improvement of their abilities? | Yes, this is done during the training period and checked in the employee evaluation. | Training Form
Employee Evaluation Form | +| 20 | Control Environment | Personnel evaluation | Do you have personnel evaluation standards? | Yes, all employee evaluations must be performed based on the standard evaluation form. | Employee Evaluation Form | +| 21 | Control Environment | Personnel evaluation | Are the personnel evaluation standards regularly reviewed and updated appropriately? | Yes, during the annual quality management audit. | Quality Management Audit Checklist | +| 22 | Risk Assessment and Response | Risk assessment structure | Is there an effective risk assessment system that involves appropriate levels of the management and managers? | Yes. | Risk Management
Risk Review
Risk Register
Processes
Process Risk Control Matrix | +| 23 | Risk Assessment and Response | Risk assessment structure | Does the management asses the risk considering not only superficial facts but also backgrounds, incidents and other substantial elements? | Yes. | Risk Management
Risk Review
Risk Register
Processes
Process Risk Control Matrix | +| 24 | Risk Assessment and Response | Risk assessment structure | Does the management appropriately assess and address fraud risks based on not only superficial facts regarding fraud, but also incentives, causes, backgrounds and other factors that may result in fraud? | Yes. | Risk Management
Risk Review
Risk Register
Processes
Process Risk Control Matrix | +| 25 | Risk Assessment and Response | Risk assessment structure | Does the management reassess the risk and take appropriate measures whenever changes occur that may have a significant impact on the company? | Yes, this is done at least annually during the risk review. | Risk Review | +| 26 | Communication and information | Communicating information | Are the management's or supervisor's instruction communicated to all employees? | Yes, this is done by providing the processes, policies and guidelines to all employees. | Processes
Policies | +| 28 | Communication and information | Internal reporting | Do you have the Whistleblower System or other internal reporting program? | Yes, there is a email address which sends the incident to all executive committee members. | compliance@karaka.app | +| 29 | Communication and information | Internal reporting | Is the system or program in operation according to its original design? | Yes, according to the annual check. | Quality Management Audit Checklist | +| 30 | Communication and information | Financial information | How does the management acquire or access the accounting and financial information of the company? | Financial information are provided during the budgeting process, monthly reporting and executive committee meeting. | Budget
Monthly Reporting
Executive Committee Meeting | +| 31 | Communication and information | Financial information | How are the accounting and financial information or data from relevant business processes input to your accounting system or application? | Partly automatic (e.g. invoice scanning, customer invoices, online orders) and partly manually (e.g. accruals, manual bookings) | | +| 32 | Communication and information | Information sharing with managements | Do you have any internal rules documents which stipulate that the managements should share business an other information with each other? | Yes, this is defined in the management process and organization guidelines. | Process: Management
Organization Guidelines | +| 33 | Communication and information | Information sharing with managements | Does your management share information with each other in actual business? | Yes. During executive committee meetings, monthly reporting and budgeting process. | Executive Committee Meeting Minutes
Monthly Reporting
Annual Budget | +| 34 | Monitoring | Ongoing monitoring | Are ongoing monitoring activities appropriately embedded within the company's overall business operations? | Yes, this is done during the monthly reporting, annual budget, executive committee meeting and risk review. | Monthly Reporting
Budget
Executive Committee Meeting Minutes
Risk Review | +| 35 | Monitoring | Ongoing monitoring | Are the ongoing monitoring activities operated appropriately according to the original designs and purposes? | Yes. | Quality Management Audit Checklist | +| 36 | Monitoring | Independent monitoring | Do you have any independent monitoring system other than ongoing monitoring activities embedded within the company's business operations, such as internal audits? | Yes. | Internal Quality Management Audit | +| 37 | Monitoring | Independent monitoring | Are the ongoing monitoring activities operated appropriately according to the original designs and purposes | Yes. | Quality Management Audit Checklist | +| 38 | Monitoring | Response to results of monitoring | Are errors, material weakness of internal controls, etc. detected through the performance of control activities or noticed from outside the company timely reported to the management or senior managers and appropriately investigated and properly addressed? | Yes, this is ensured through the executive committee meeting, risk review, internal audit and Whistleblower system. | Executive Committee Meeting Minutes
Risk Review
Internal Quality Management Audit | diff --git a/Processes/COSO/ITGC.md b/Processes/COSO/ITGC.md index c9bf85a..f462b48 100644 --- a/Processes/COSO/ITGC.md +++ b/Processes/COSO/ITGC.md @@ -11,59 +11,59 @@ ## General -| No. | Component | Control Area | Question | Answer | Evidence | -| ---- | --------- | ------------ | ------------------------------------------------------------ | ------ | -------- | -| | IT | IT Strategy | Do you have a IT investment strategy or plan? | | | -| | IT | IT Strategy | Are the IT investment strategies or plans reviewed and approved by the management? | | | +| No. | Component | Control Area | Question | Answer | Evidence | +| ---- | --------- | ------------ | ------------------------------------------------------------ | ------------------------------------------------------------ | ----------------------------------------------- | +| | IT | IT Strategy | Do you have a IT investment strategy or plan? | Yes, investments are evaluated at least annually during the budget process. Additionally, resources are also checked regularly (e.g. executive committee meeting). | Budget
Executive Committee Meeting Minutes | +| | IT | IT Strategy | Are the IT investment strategies or plans reviewed and approved by the management? | Yes, during the budget process and if outside the budget in the executive committee meeting. | Budget
Executive Committee Meeting Minutes | ## System Development and Maintenance ### Points to consider -| Overview | Component | Situation | Evidence | -| -------------------- | --------- | ------------------------------------------------------------ | -------- | -| Frequency of changes | A | Often changes are required for various reasons (e.g. functionality enhancement changes in business processes, etc.) | | -| Frequency of changes | OS, DB | Changes are made for each release of security patches/upgrades | | -| Frequency of changes | N, O | Changes are made for each release of patches/upgrades | | +| Overview | Component | Situation | Evidence | +| -------------------- | --------- | ------------------------------------------------------------ | ---------------------------------- | +| Frequency of changes | A | Often changes are required for various reasons (e.g. functionality enhancement changes in business processes, etc.) | CHANGELOG
Software validation | +| Frequency of changes | OS, DB | Changes are made for each release of security patches/upgrades | Software validation | +| Frequency of changes | N, O | Changes are made for each release of patches/upgrades | Software validation | ### Assessment of Design Effectiveness -| No. | Question | Component | Situation | Evidence | -| ---- | ------------------------------------------------------------ | --------------- | ------------------------------------------------------------ | -------- | -| 1 | Policies and procedures for development and maintenance are described in a formal way | A, OS, DB, N, O | Documentations are prepared by the IT team and authorized by the head of IT | | -| 2 | Roles and responsibilities concerning development and maintenance are clearly defined | A, OS, DB, N, O | IT personnel incl. service vendors perform changes | | -| 3 | Changes are tested and their results are approved | A, OS, DB, N, O | | | -| 4 | Changes are approved for their migration to the production environment | | | | -| 5 | Procedures are in place for preventing/detecting unauthorized changes to the production environment | | | | +| No. | Question | Component | Situation | Evidence | +| ---- | ------------------------------------------------------------ | --------------- | ------------------------------------------------------------ | ------------------------------------------------------------ | +| 1 | Policies and procedures for development and maintenance are described in a formal way | A, OS, DB, N, O | Documentations are prepared by the IT team and authorized by the head of IT | Process: Development
Process: Support & Service
Policies: IT | +| 2 | Roles and responsibilities concerning development and maintenance are clearly defined | A, OS, DB, N, O | IT personnel incl. service vendors perform changes | Process: Development
Process: Support & Service
Organigram | +| 3 | Changes are tested and their results are approved | A, OS, DB, N, O | Before updates for third party software are performed on the servers they are tested in a testing environment. Self-developed software changes are tested according the development process. | Third party: Software validation
Process: Development
Internal: Test protocols | +| 4 | Changes are approved for their migration to the production environment | A, OS, DB, N, O | The change in the production environment is approved by the head of IT for third party software and for self-developed changes according the development process. | Third party: Software validation
Process: Development
Internal: Merge protocol | +| 5 | Procedures are in place for preventing/detecting unauthorized changes to the production environment | A, OS, DB, N, O | Only the head of IT can install updates on the servers. Only the head of IT has the necessary IT authentication and IT permission. For self-developed changes all changes, merges can only be performed from authorized personnel and all merges are logged in merging protocols. | Permission List | ## System Security (Access Control) ### Points to consider -| Question | Component | Situation | Evidence | -| ------------------------------------------------------------ | ------------ | ------------------------------------------------------------ | -------- | -| Number of users | A | Large number of users in large number of user locations/departments | | -| Number of users | OS, DB, N, O | Number of users and user locations/departments is limited | | -| Frequency of "direct data change"

("direct data change" means to change data with the utilities such as SQL software) | N | No direct change to data has been required since its implementation, as the system has been in stable operation | | +| Question | Component | Situation | Evidence | +| ------------------------------------------------------------ | ------------ | ------------------------------------------------------------ | ------------------------------- | +| Number of users | A | Large number of users in large number of user locations/departments | Organigram
Permission List | +| Number of users | OS, DB, N, O | Number of users and user locations/departments is limited | Organigram
Permission List | +| Frequency of "direct data change"

(*"direct data change" means to change data with the utilities such as SQL software*) | N | No direct change to data has been required since its implementation, as the system has been in stable operation | | ### Assessment of Design Effectiveness -| No. | Question | Component | Situation | Evidence | -| ---- | ------------------------------------------------------------ | --------------- | ------------------------------------------------------------ | -------- | -| 1 | User authentication is required | A, OS, DB, N, O | User-ID and password are assigned on an individual basis | | -| 2 | User and access rights granted to each user are documented | A | A list of users is prepared with the rights granted to each user. This list is generated from the system | | -| 2 | User and access rights granted to each user are documented | A, OS, DB, N, O | A list of users is prepared with the rights granted to each user | | -| 3 | Policies and procedures for user-ID administration (add, change, remove, and periodic user validation) are described in an authorized documentation | A, OS, DB, N, O | The documentation is prepared and authorized by the head of IT | | -| 4 | Periodic user validation is performed, this means each user's access rights are reviewed on a periodic basis | A, OS, DB, N, O | Performed both in terms of existence of user and the detailed access rights granted to each user-ID on an annual basis by the head of IT | | -| 5 | User-ID administration requests are approved by managers in user dpt. and/or IT dpt, as appropriate | A, OS, DB, N, O | Records are maintained in the change management | | -| 6 | Access to privileged IT functions is restricted to appropriate personnel | A, OS, DB, N, O | These functions are restricted to IT personnel. Logs of the use of such privileged user-IDs are reviewed annualy | | -| 7 | The level of complexity in password settings are appropriate | A, OS, DB, N, O | Password complexity is configured based on a minimum length of 8, at least one upper case letter, at least one lower case letter, at least one special character and at least one numeric value. Password changes must happen every 3 months | | -| 8 | Policies and procedures for direct change to data are descripted in a documentation | DB | Only the head of IT may perform and authorize direct changes to the data | | -| 9 | Direct change to data are authorized | DB | No direct changes to data where made | | -| 10 | Direct change to data are tested | DB | No direct changes to data where made | | -| 11 | Access to DB and/or utilities for direct change to data is restricted to appropriate personnel | DB | Only the head of IT has write/change permissions to the DB | | -| 12 | Physical access to computer hardware is restricted to appropriate personnel | A, OS | Data and programs are in a stand-alone PC in control of the user. User permissions for Applications and OS are restricted appropriately | | -| 12 | Physical access to computer hardware is restricted to appropriate personnel | DB | Server(s) are located in a machine room with appropriate physical access control | | +| No. | Question | Component | Situation | Evidence | +| ---- | ------------------------------------------------------------ | --------------- | ------------------------------------------------------------ | ------------------------------------------------------------ | +| 1 | User authentication is required | A, OS, DB, N, O | User-ID and password are assigned on an individual basis | Application login screen
OS login screen
DB login screen
Server login screen | +| 2 | User and access rights granted to each user are documented | A | A list of users is prepared with the rights granted to each user. This list is generated from the system | Application permission List | +| 2 | User and access rights granted to each user are documented | OS, DB, N, O | A list of users is prepared with the rights granted to each user | Permission List | +| 3 | Policies and procedures for user-ID administration (add, change, remove, and periodic user validation) are described in an authorized documentation | A, OS, DB, N, O | The documentation is prepared and authorized by the head of IT | | +| 4 | Periodic user validation is performed, this means each user's access rights are reviewed on a periodic basis | A, OS, DB, N, O | Performed both in terms of existence of user and the detailed access rights granted to each user-ID on an annual basis by the head of IT | | +| 5 | User-ID administration requests are approved by managers in user dpt. and/or IT dpt, as appropriate | A, OS, DB, N, O | Records are maintained in the change management | | +| 6 | Access to privileged IT functions is restricted to appropriate personnel | A, OS, DB, N, O | These functions are restricted to IT personnel. Logs of the use of such privileged user-IDs are reviewed annually | | +| 7 | The level of complexity in password settings are appropriate | A, OS, DB, N, O | Password complexity is configured based on a minimum length of 8, at least one upper case letter, at least one lower case letter, at least one special character and at least one numeric value. Password changes must happen every 3 months | | +| 8 | Policies and procedures for direct change to data are descripted in a documentation | DB | Only the head of IT may perform and authorize direct changes to the data | | +| 9 | Direct change to data are authorized | DB | No direct changes to data where made | | +| 10 | Direct change to data are tested | DB | No direct changes to data where made | | +| 11 | Access to DB and/or utilities for direct change to data is restricted to appropriate personnel | DB | Only the head of IT has write/change permissions to the DB | | +| 12 | Physical access to computer hardware is restricted to appropriate personnel | A, OS | Data and programs are in a stand-alone PC in control of the user. User permissions for Applications and OS are restricted appropriately | | +| 12 | Physical access to computer hardware is restricted to appropriate personnel | DB | Server(s) are located in a machine room with appropriate physical access control | | ## System Operation and Administration @@ -81,7 +81,7 @@ | ---- | ------------------------------------------------------------ | ----------------------------------------------------------- | -------- | | 1 | Policies and procedures for backups | Exists | | | 2 | Completion of backup is ensured | All backup job records are reviewed by monitoring personnel | | -| 3 | Backup and recovery are periodically tested | | | +| 3 | Backup and recovery are periodically tested | Every backup is automatically tested | | | 4 | Policies and procedures for job operation are described in a documentation | | | | 5 | Job schedule changes are approved | | | | 6 | Procedures are in place for preventing/detecting unauthorized changes to job schedules | | | @@ -94,9 +94,9 @@ ### Points to consider -| Question | Situation | Evidence | -| ---------------------------- | ------------------------------------------------------------ | -------- | -| What services are outsourced | Some of the services are outsourced concerning development/maintenance related to ITGCs | | +| Question | Situation | Evidence | +| ---------------------------- | ------------------------------------------------------------ | ------------------------- | +| What services are outsourced | Some of the services are outsourced concerning development/maintenance related to ITGCs | Software vendor contracts | ### Assessment of Design Effectiveness diff --git a/Processes/COSO/Risk Management/Risk Management Review Template.md b/Processes/COSO/Risk Management/Risk Management Review Template.md index 9abbcf3..c6d54e1 100644 --- a/Processes/COSO/Risk Management/Risk Management Review Template.md +++ b/Processes/COSO/Risk Management/Risk Management Review Template.md @@ -1,36 +1,8 @@ # Risk Management Review Template -## Risk Identification - -### New risks - -| Risk No. | R | Category | Risk Event | L | C | O | Mitigation Type | Mitigation Strategy | L* | C* | Changes | Comments | ES | EY | -| -------- | ---- | -------- | ---------- | ---- | ---- | ---- | --------------- | ------------------- | ---- | ---- | ------- | -------- | ---- | ---- | -| | | | | | | | | | | | | | | | - -Abbreviations: - -* R: Responsible -* L: Likelihood (1-5) -* C: Consequence (1-5) -* L\*/C\*: Likelihood and Consequence after mitigation -* O: Occurrence (many times a day, daily, weekly, monthly, annually) -* ES: Effective -* EY: Efficient - -### Old risks (no longer applicable) - -| Risk No. | R | Category | Risk Event | Reason for removal | -| -------- | ---- | -------- | ---------- | ------------------ | -| | | | | | - -Abbreviations: - -* R: Responsible - ## Risk Monitoring -For details see the risk register. +For details see the [Risk Register](Risk%20Register.md) and the Risk Control Matrix of every process. ### Key Risks @@ -56,6 +28,34 @@ For details see the risk register. #### Risk XXX +## Risk Identification + +### New risks + +| Risk No. | R | Category | Risk Event | L | C | O | Cause | Mitigation Type | Mitigation Strategy | L* | C* | Changes | Comments | ES | EY | +| -------- | ---- | -------- | ---------- | ---- | ---- | ---- | ----- | --------------- | ------------------- | ---- | ---- | ------- | -------- | ---- | ---- | +| | | | | | | | | | | | | | | | | + +Abbreviations: + +* R: Responsible +* L: Likelihood (1-5) +* C: Consequence (1-5) +* L\*/C\*: Likelihood and Consequence after mitigation +* O: Occurrence (many times a day, daily, weekly, monthly, annually) +* ES: Effective +* EY: Efficient + +### Old risks (no longer applicable) + +| Risk No. | R | Category | Risk Event | Reason for removal | +| -------- | ---- | -------- | ---------- | ------------------ | +| | | | | | + +Abbreviations: + +* R: Responsible + ## Effectiveness The risk mitigation strategies are very effective as no damages from identified risks occurred and no significant unidentified risks were found. @@ -64,7 +64,7 @@ The risk management operates as designed and is effective. ## Efficiency -The risk management is implemented with reasonable amounts of human resources, low costs due to internal risk management and very good preventing and discovering results as seen in the effectiveness. +The risk management is implemented with reasonable amounts of human resources, low costs due to internal risk management and very good preventing and discovering results as described in the effectiveness. ## Summary @@ -72,6 +72,6 @@ The risk management is implemented with reasonable amounts of human resources, l - +NAME, LAST NAME -2022.12.31 +2022-12-31 diff --git a/Processes/COSO/Risk Management/Risk Register.md b/Processes/COSO/Risk Management/Risk Register.md index 8ce5a7b..e10f831 100644 --- a/Processes/COSO/Risk Management/Risk Register.md +++ b/Processes/COSO/Risk Management/Risk Register.md @@ -1,15 +1,15 @@ # Risk Register -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. +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. Additional risks can be found in the corresponding **Risk Control Matrix** of every process. -| No. | R | Category | Risk Event | L | C | O | Mitigation Type | 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 | -| 3 | DE | Operational Risk | User acquires additional permissions without authorization (every software which uses permissions) | 2 | 5 | | | Avoiding: Permissions can only be granted by users which have received the permissions to do so. Users which can change permissions may also only have the permission to change specific users/permissions (single application elements, not the whole application.). We provide a documentation on who to manage permissions incl. best practices. Customers with a maintenance contract also receive additional advice based on their account permission handling. We also check regularly if features can be used by default without the necessary permissions. | | | | The consequences or severities depend on the permissions which can be acquired. | yes | yes | -| 4 | DE | Operational Risk | User code execution (every software which allows data upload/input) | 3 | 5 | | | Avoiding: User provided code is a critical part of some modules (e.g. Helper, Job). These modules provided by OMS execute code user code in iframes. We provide guidelines regarding this sensitive topic which explains that only developers in a company should have access to such functionalities. | | | | | yes | yes | -| 5 | DE | Operational Risk | Data leak (e.g. database data, file uploads) (every software which stores data) | 2 | 5 | | | Avoiding: We regularly check if users have access to data without the necessary permissions. Our modules may use encryption for extremely sensitive data. Media files are only accessible through the media module which allows to check the necessary reading permissions. We also provide a general policy for customers who to secure and maintain their servers. | | | | This is a big problem for almost every company working with data. The biggest known leaks happened among others to Adobe, ebay, Equifax, LinkedIn, Yahoo, ... | yes | yes | -| 6 | DE | Operational Risk | Corrupt/malicious data injection (every software which accepts data input) | 3 | 3 | | | Avoiding: Data is validated client side (minimal protection) and server side. Generally, user input is only accepted if it matches the specified allowed format. Data is usually not sanitized to avoid mistakes during the sanitizing process. Database query statements are prepared and encoded. | | | | | yes | yes | +| No. | R | Category | Risk Event | L | C | O | Cause | Mitigation Type | 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 | +| 3 | DE | Operational Risk | User acquires additional permissions without authorization (every software which uses permissions) | 2 | 5 | | | | Avoiding: Permissions can only be granted by users which have received the permissions to do so. Users which can change permissions may also only have the permission to change specific users/permissions (single application elements, not the whole application.). We provide a documentation on who to manage permissions incl. best practices. Customers with a maintenance contract also receive additional advice based on their account permission handling. We also check regularly if features can be used by default without the necessary permissions. | | | | The consequences or severities depend on the permissions which can be acquired. | yes | yes | +| 4 | DE | Operational Risk | User code execution (every software which allows data upload/input) | 3 | 5 | | | | Avoiding: User provided code is a critical part of some modules (e.g. Helper, Job). These modules provided by OMS execute code user code in iframes. We provide guidelines regarding this sensitive topic which explains that only developers in a company should have access to such functionalities. | | | | | yes | yes | +| 5 | DE | Operational Risk | Data leak (e.g. database data, file uploads) (every software which stores data) | 2 | 5 | | | | Avoiding: We regularly check if users have access to data without the necessary permissions. Our modules may use encryption for extremely sensitive data. Media files are only accessible through the media module which allows to check the necessary reading permissions. We also provide a general policy for customers who to secure and maintain their servers. | | | | This is a big problem for almost every company working with data. The biggest known leaks happened among others to Adobe, ebay, Equifax, LinkedIn, Yahoo, ... | yes | yes | +| 6 | DE | Operational Risk | Corrupt/malicious data injection (every software which accepts data input) | 3 | 3 | | | | Avoiding: Data is validated client side (minimal protection) and server side. Generally, user input is only accepted if it matches the specified allowed format. Data is usually not sanitized to avoid mistakes during the sanitizing process. Database query statements are prepared and encoded. | | | | | yes | yes | ## Abbreviations diff --git a/Processes/Finance/Reporting/Monthly Reporting Checklist.md b/Processes/Finance/Reporting/Monthly Reporting Checklist.md index bf81b6c..516e590 100644 --- a/Processes/Finance/Reporting/Monthly Reporting Checklist.md +++ b/Processes/Finance/Reporting/Monthly Reporting Checklist.md @@ -19,6 +19,7 @@ | 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 | | | | +| Explanation for sales and costs (provided by head of departments) | CFO | | | | diff --git a/Legal/.~age Agreement.docx b/Processes/HR/Hiring/.~sting Layout_en.docx similarity index 100% rename from Legal/.~age Agreement.docx rename to Processes/HR/Hiring/.~sting Layout_en.docx diff --git a/Processes/IT/Automated Jobs.md b/Processes/IT/Automated Jobs.md index 07807f2..e4765fa 100644 --- a/Processes/IT/Automated Jobs.md +++ b/Processes/IT/Automated Jobs.md @@ -11,5 +11,7 @@ | Push master branch to remote server | Daily | 03:00 | | | Demo application setup | Daily | 03:00 | | + + 2022-01-01 - Version 1.0 diff --git a/Processes/IT/IT Equipment & Software.md b/Processes/IT/IT Equipment & Software.md index 125ae24..6515753 100644 --- a/Processes/IT/IT Equipment & Software.md +++ b/Processes/IT/IT Equipment & Software.md @@ -57,3 +57,7 @@ | C++ compilation tool | CMake | | Remote connection | ssh | + + +2022-01-01 - Version 1.0 + diff --git a/Processes/IT/Permission List.md b/Processes/IT/Permission List.md new file mode 100644 index 0000000..8aef45a --- /dev/null +++ b/Processes/IT/Permission List.md @@ -0,0 +1,39 @@ +# Permission List + +The following list only contains user permissions of A, OS, DB, N, O which are running on the server or remote services. Local software is not often not mentioned. Detailed permissions can be accessed in the respective software. + +| Group / User | DB | OS / Server | N | Local OS | Firewall/Anti-Virus | github | +| -------------------------- | ----- | ------------- | ------------- | ------------- | ------------------- | ---------------------------------------- | +| General | None | None | None | User | None | None | +| IT | Read | Configuration | Configuration | Configuration | Configuration | Configuration | +| IT: Head of IT | Admin | Admin | Admin | Admin | Admin | Admin | +| Development | None | None | None | Configuration | None | Pull, push
Issues: Admin | +| Development: Code Reviewer | None | None | None | Configuration | None | Pull, push
Issues: Admin
Merge | +| Support & Service | None | None | None | Configuration | None | Issues: Admin | +| CTO | Admin | Admin | Admin | Admin | Admin | Admin | +| Quality Management | None | None | None | User | None | None | +| Finance | None | None | None | User | None | None | +| Purchase | None | None | None | User | None | None | +| HR | None | None | None | User | None | None | +| CFO | None | None | None | User | None | None | +| Sales | None | None | None | User | None | None | +| Marketing | None | None | None | User | None | None | +| CSO | None | None | None | User | None | None | +| Management | None | None | None | User | None | None | + +## Permission details + +* User: Has no permission to install software, change permissions or change configurations +* Admin: Has all permissions +* None: No (direct) permissions. Permissions and functionality might be handled by intermediatory software. + +## Abbreviations + +* OS: Operating System +* DB: DBMS +* N: Network + + + +2022-01-01 - Version 1.0 + diff --git a/Processes/IT/Third Party Software Validation - New.md b/Processes/IT/Third Party Software Validation - New.md index 75b8204..8f39554 100644 --- a/Processes/IT/Third Party Software Validation - New.md +++ b/Processes/IT/Third Party Software Validation - New.md @@ -25,3 +25,8 @@ Before buying/implementing a new software the following aspects must be checked: | Estimated cost savings (one-off/annual) | | Investment Form | | | Estimated ROI in years | | Investment Form | | | Opinion project manager | | See above | | + + + +2022-01-01 - Version 1.0 + diff --git a/Processes/IT/Third Party Software Validation - Update.md b/Processes/IT/Third Party Software Validation - Update.md index 80de068..886a0f0 100644 --- a/Processes/IT/Third Party Software Validation - Update.md +++ b/Processes/IT/Third Party Software Validation - Update.md @@ -1 +1,6 @@ # Third Party Software Validation - Update + + + +2022-01-01 - Version 1.0 + diff --git a/Processes/Management/Business Model Canvas.md b/Processes/Management/Business Model Canvas.md new file mode 100644 index 0000000..dfeb3ed --- /dev/null +++ b/Processes/Management/Business Model Canvas.md @@ -0,0 +1,55 @@ +# Business Model Canvas + +### Key Partners + +* Hosting provider in case of online hosting +* Virtual machine software providers + +### Key Activities + +* Develop business software +* Provide software support and maintenance +* Software customization + +### Key Resources + +* Developers +* Support staff + +### Value Proposition + +* All-in-one business software solution +* Affordable even for small businesses +* Modular software + +### Customer Relationships + +* Transactional +* Support & Maintenance +* Consulting +* Customization + +### Channels + +* Primarily web and self serve +* Secondarily print media +* Thirdly exhibitions and events + +### Customer Segments + +* Small to medium sized businesses who need multiple software solutions or integrated functionality between software components + +### Cost + +* Development staff +* Support staff +* HR in general +* Managing sales channels +* Hosting + +### Revenue + +* Recurring software license fees +* Maintenance contract fees +* Hosting +* Customizations \ No newline at end of file diff --git a/Processes/Management/Business Plan.md b/Processes/Management/Business Plan.md index f7ca2a3..07971a3 100644 --- a/Processes/Management/Business Plan.md +++ b/Processes/Management/Business Plan.md @@ -8,149 +8,11 @@ The main goal of the organization is to create solutions for companies and organ ### SWOT -#### Strengths +See [SWOT](SWOT.md). -##### From Customer PoV +## Business model canvas -* Everything in one application. Organizations and businesses no longer have to use multiple services from different providers and potentially integrate them into their existing applications -* Cheap for the customer compared to many other solutions -* Easy to use with modern visuals and layouts -* Good performance -* Modular. The customer can decide which modules he needs -* Solves real problems. Features are drafted and tested by business specialists in the respective fields -* Optimized for mobile and desktop -* Flexible setup (local or remote) -* Regular updates. Either manually or automatically -* Large amount of modules and functionality - -##### Technical PoV - -* Modular structure is designed in a very scalable way -* Multiple database support (mssql, mysql, postgresql) -* Multiple cache support (file, memcache, redis) -* Easily scalable -* Can be split across multiple servers - -#### Weaknesses - -##### From Customer PoV - -* Installation for non-tech people is "difficult" (not the actual app installation but the WAMP or LAMP installation) - -##### Technical PoV - -* Request based code execution. Database and cache connection is request based and not persistent etc. therefor slower and more complicated to maintain state -* Concurrency is difficult to solve due to the request based code execution and state storage - -#### Opportunities - -* Continuous digitalization, automation and need to keep up with it -* Price attractiveness for all sizes of organizations and businesses -* Public free software tests (without registration) -* Growing demand for managing data (also for small businesses) - -##### Technical PoV - -* Programming language performance improvement through parallelization/asynchronism implementation -* Programming language performance improvement through usage of type hints during compilation -* Switch to a different language (e.g. c, c++, c#) for higher perform, parallelization and state - -#### Threats - -##### External - -* Regulations. There are many different regulations for different regions and business fields that must be upheld -* Small customers still want to own software and not rent it and pay for it every year -* Since software is intangible it is generally attributed with a lower value than tangible assets -* Like for every programming language the general support for the language (updates, bug fixes, improvements) - -##### Internal - -* Own organization size/workload. A large amount of modules and tools are required to reach the critical size to make a product which is beneficial for a large amount of organizations and businesses - -### Strategy & Vision - -#### Vision - -* **Early:** Karaka solutions are used by at least 1.000 organizations/businesses in 2025 -* **Late:** Karaka is one of the industry standard solution provider for organizations and businesses - -##### Goal - -1. Focus on the solution of the problem -2. Financially attractiveness for as many end-users as possible -3. Solve a wide range of problems -4. Integrate solutions for seamless workflows -5. Accessible for everyone (desktop, tablet, phone, for disabled people, online/offline) -6. Fast user interface feedback and good performance - -##### How To Achieve? - -1. Use it during development incl. user feedback -2. Modular system and fair pricing -3. Speak to users and implement common workflows -4. One philosophy and one core system for every module -5. Put the user experience above ease of implementation -6. Specialized software implementations instead of generalized solutions. - -#### Strategy - -##### Initial Phase - -###### Customer - -In the beginning the goal is to reach a large amount of organizations no matter the size. As it is easier to address smaller organizations since they usually are less invested in existing software solutions they will be the initial target group. For them no customization will be done unless they can be integrated for everyone. - -For these customers the following points are most important: - -1. Price -2. Ease of use -3. Key modules - -###### Price - -The price should be very competitive. This could be achieved by providing a cheap basic package which includes the essentials for most organizations with a license for up to **5** users. There could be different packages for different types of organizations. However a small organization should look at a package and immediately recognize that this basically contains everything they need. Small organizations need to have trust in a product without having to understand all the technical details of functionality which may be required for larger organizations. - -At the same time the customer needs to be informed, that he can customize his package if he wants to (e.g. add additional modules). Only after providing these information the customer needs to be informed that he can also completely customize his modules if he so desires without a basic package. For mid to large sized organizations other price strategies could be better. - -A basic package should not cost more than 10 EUR per month as this is comparable to other competitors. Competitors offer overall much less but compared to the *basic* package they either provide similar features or the user will have a difficult time to understand why he has to pay more. - -###### Ease of use - -Ease of use needs to be visible to the customer even before he purchases a package. In order portray that of course the modules themselves have to be designed in a very intuitive way but also the available documentation has to be very easy to understand. Very often documentations expect a certain amount of pre-knowledge which confuses new users if they try to follow a documentation step-by-step. At the same time videos are very important for small organizations as they may rather watch a video than read through the documentation. - -The videos should not have a long introduction and an outro which are very annoying if you want to go through some videos very fast and have to waste your time on intros and outros. The solution will be to only show a 3 sec image or splash screen as intro and an 3 sec outro image with contact, website and documentation details. - -The videos should be around 5 - 15 minutes long. Shorter than 5 minutes will lead to a large amount of videos which take time to search through and longer than 15 minutes will discourage users since they might not want to invest the time. - -Some of the demo applications need to be targeted to small sized organizations so that they can immediately see and test the application and modules that they would also use themselves. Additionally the UI needs to look modern and simple in order to convey the ease of use. - -###### Key modules - -The key modules in one package must give the user the impression that this includes all the basics he needs to manage the organization. - -Recommended modules for businesses are: - -* Admin -* Organization -* Media -* Tasks -* Media -* Calendar -* Message -* Accounting -* P&L -* ClientManagement -* SupplierManagement -* Invoicing -* Payment reminder -* CashManagement -* Banking (FinTS/HBCI, EBICS) -* ItemManagement -* VoucherManagement -* TaxManagement - -With these modules almost every small business could operate. Smart advertisements could help to sell extending modules such as charting, balancing, cost center accounting, cost object accounting, warehousing etc. +See [Business Model Canvas](Business%20Model%20Canvas.md) ## Products & Services diff --git a/Processes/Management/Executive Committee Minute Template.md b/Processes/Management/Executive Committee Minute Template.md new file mode 100644 index 0000000..8fa4595 --- /dev/null +++ b/Processes/Management/Executive Committee Minute Template.md @@ -0,0 +1,98 @@ +# Executive Committee Minute: YYYY-MM-DD + +## Members + +Present: XXX (CEO), XXX (CFO), XXX (CSO), XXX (CTO), XXX (HR) + +Guests: None + +Absent: None + +Keeper of the minutes: CEO + +Moderator: CEO + +## Management report (by CEO) + +### Quality Management + +No topics to report. + +## Finance report (by CFO) + +| Topics in 1 000 EUR | PY (YTD) | Budget (YTD) | Actual (YTD) | Diff PY (in %) | Diff (in %) | +| ------------------- | -------- | ------------ | ------------ | -------------- | ----------- | +| Sales | | | | | | +| HR | | | | | | +| Marketing | | | | | | +| EBIT | | | | | | +| Cash | | | | | | + +Investments: All investments are within budget. + +### Purchase + +No topics to report. + +## Sales report (by CSO) + +| Region in 1 000 EUR | PY (YTD) | Budget (YTD) | Actual (YTD) | Diff PY (in %) | Diff (in %) | +| ------------------- | -------- | ------------ | ------------ | -------------- | ----------- | +| Domestic | | | | | | +| Europe | | | | | | +| America | | | | | | +| Other | | | | | | + +| Type in 1 000 EUR | PY (YTD) | Budget (YTD) | Actual (YTD) | Diff PY (in %) | Diff (in %) | +| --------------------- | -------- | ------------ | ------------ | -------------- | ----------- | +| License | | | | | | +| Support & Maintenance | | | | | | +| Hosting | | | | | | +| Customization | | | | | | +| Other | | | | | | + +### Market situation + +#### Macroeconomics + +#### Microeconomic + +### Marketing + +No topics to report. + +## Development, Support & Service report (by CTO) + +| Important Tasks & Projects & Milestones | Deadline (YYYY-MM-DD) | Status | Completed (YES/NO) | +| --------------------------------------- | --------------------- | ------ | ------------------ | +| | | | | +| | | | | +| | | | | + +Customer satisfaction: XX + +### IT + +No topics to report. + +## HR report (by Head of HR) + +### Vacant positions + +None + +### Filled positions + +None + +## Risks and benefit assessment (by CEO) + +All members report, that no new risks or benefits exist which require a risk benefit assessment. + +## Resource assessment (by CEO) + +All members report, that the resources are sufficient to ensure the ongoing of the normal business operations. + +## Important upcoming events + +None \ No newline at end of file diff --git a/Processes/Management/SWOT.md b/Processes/Management/SWOT.md new file mode 100644 index 0000000..97ee31f --- /dev/null +++ b/Processes/Management/SWOT.md @@ -0,0 +1,61 @@ +# SWOT + +#### Strengths + +##### From Customer PoV + +* Everything in one application. Organizations and businesses no longer have to use multiple services from different providers and potentially integrate them into their existing applications +* Cheap for the customer compared to many other solutions +* Easy to use with modern visuals and layouts +* Good performance +* Modular. The customer can decide which modules he needs +* Solves real problems. Features are drafted and tested by business specialists in the respective fields +* Optimized for mobile and desktop +* Flexible setup (local or remote) +* Regular updates. Either manually or automatically +* Large amount of modules and functionality + +##### Technical PoV + +* Modular structure is designed in a very scalable way +* Multiple database support (mssql, mysql, postgresql) +* Multiple cache support (file, memcache, redis) +* Easily scalable +* Can be split across multiple servers + +#### Weaknesses + +##### From Customer PoV + +* Installation for non-tech people is "difficult" (not the actual app installation but the WAMP or LAMP installation) + +##### Technical PoV + +* Request based code execution. Database and cache connection is request based and not persistent etc. therefor slower and more complicated to maintain state +* Concurrency is difficult to solve due to the request based code execution and state storage + +#### Opportunities + +* Continuous digitalization, automation and need to keep up with it +* Price attractiveness for all sizes of organizations and businesses +* Public free software tests (without registration) +* Growing demand for managing data (also for small businesses) + +##### Technical PoV + +* Programming language performance improvement through parallelization/asynchronism implementation +* Programming language performance improvement through usage of type hints during compilation +* Switch to a different language (e.g. c, c++, c#) for higher perform, parallelization and state + +#### Threats + +##### External + +* Regulations. There are many different regulations for different regions and business fields that must be upheld +* Small customers still want to own software and not rent it and pay for it every year +* Since software is intangible it is generally attributed with a lower value than tangible assets +* Like for every programming language the general support for the language (updates, bug fixes, improvements) + +##### Internal + +* Own organization size/workload. A large amount of modules and tools are required to reach the critical size to make a product which is beneficial for a large amount of organizations and businesses \ No newline at end of file diff --git a/Processes/Organigram.md b/Processes/Organigram.md index 33fc60d..d61daa4 100644 --- a/Processes/Organigram.md +++ b/Processes/Organigram.md @@ -22,3 +22,4 @@ graph TD; ``` 2022-01-01 - Version 1.0 + diff --git a/Processes/Purchase/Key Supplier Evaluation.md b/Processes/Purchase/Key Supplier Evaluation.md new file mode 100644 index 0000000..b4e63b6 --- /dev/null +++ b/Processes/Purchase/Key Supplier Evaluation.md @@ -0,0 +1,17 @@ +# Key Supplier Evaluation + +| Name | Products & Services | Description | Annual amount | Type | Dependency risk | Alternative evaluation | Quality evaluation | Last evaluated by | Last evaluated | +| ---------- | ----------------------------------------- | --------------------------- | ------------- | --------------- | --------------- | ------------------------------------------------------------ | ------------------------------------------------------------ | ----------------- | -------------- | +| Oracle | VirtualBox | Machine virtualization | 0 EUR | single purchase | very low | Alternative solutions such as VMWare or KVM don't provide any significant benefits for the general use case. Customers can still choose a different solution regardless. | No significant issues | Dennis Eichhorn | 2022-01-01 | +| PHPOffice | PhpSpereadsheet, PHPWord, PHPPresentation | Office software | 0 EUR | single purchase | medium | No alternative supplier could be found which combines all three products and same functionality. Solutions which cover a single aspect are available but more inconvenient to use. | No significant issues but the performance (e.g. memory usage) limits the use cases and requires parallelizing certain tasks. | Dennis Eichhorn | 2022-01-01 | +| mPDF | mPDF | PDF renderer | 0 EUR | single purchase | low | Alternative solutions don't provide the same level of html/css rendering capabilities. Alternatives are also available through PHPWord or tcpdf. | No significant issues. | Dennis Eichhorn | 2022-01-01 | +| Tecnick | tcpdf | PDF renderer | 0 EUR | single purchase | low | Fastest php pdf renderer. Alternatives are also available through PHPWord or mpdf. | No significant issues. | Dennis Eichhorn | 2022-01-01 | +| TeamViewer | TeamViewer | Remote desktop connection | | subscription | very low | No alternative is as conveniently to use or is as broadly implemented (works on many different OS). It is the most well established remote desktop connection tool for support purposes. Alternatives VNC solutions could work as a fall back in a worst case situation. | No significant issues. | Dennis Eichhorn | 2022-01-01 | +| Microsoft | github | Source code version control | 0 EUR | subscription | very low | The closest alternative is gitlab. However, github is the most established solution which is simple to use and provides the necessary functionality. It's also possible to host alternative solutions on the company servers in a worst case situation. | No significant issues. | Dennis Eichhorn | 2022-01-01 | + +> Single purchase can also mean one time download for software without any dependency on other services. + + + +2021-01-01 - Version 1.0 + diff --git a/Processes/Quality Management/Internal Quality Management Audit Form.md b/Processes/Quality Management/Internal Quality Management Audit Form.md new file mode 100644 index 0000000..825b9be --- /dev/null +++ b/Processes/Quality Management/Internal Quality Management Audit Form.md @@ -0,0 +1,2 @@ +# Internal Quality Management Audit Form + diff --git a/Processes/Quality Management/Quality Management Audit Checklist.md b/Processes/Quality Management/Quality Management Audit Checklist.md new file mode 100644 index 0000000..969af68 --- /dev/null +++ b/Processes/Quality Management/Quality Management Audit Checklist.md @@ -0,0 +1,16 @@ +# Quality Management Audit Checklist + +| Todo | Responsible | Date | +| ------------------------------------------------------------ | ----------- | ---- | +| Check process key objective achievement | | | +| Check annual risk management review | | | +| Check previous audit remarks | | | +| Check that the processes, guidelines, policies, checklists and forms up to date | | | +| Check if all document changes are approved if necessary | | | +| Is the Whistleblower System working according to design? | | | +| Check if the annual internal quality management audit was performed | | | + + + +2022-01-01 - Version 1.0 +